Re: WheelEvent of DOM Level 3 Events now landed
On 2012/08/13 18:19, Masayuki Nakano wrote: On 2012/08/13 17:32, Neil wrote: Masayuki Nakano wrote: On 2012/08/13 4:57, Neil wrote: it seems as if you can't make the wheel scroll more slowly any more? Currently, yes. The reason for not supporting slower scrolling isn't technical reason. It needs some additional code. E.g., 0.5px scroll isn't supported by current ESM. Do you just ignore left-over fractions of pixels created e.g by scrolling 37% faster (delta_multiplier = 137)? Yes. http://hg.mozilla.org/mozilla-central/annotate/038266727ddc/content/events/src/nsEventStateManager.cpp#l2854 With a couple of additional bug fixes, the fraction pixel values are now stored and used at next event handling if the direction hasn't been changed. https://bugzilla.mozilla.org/show_bug.cgi?id=422132 And now, the multiplier settings allow slower value (less than 1.0). https://bugzilla.mozilla.org/show_bug.cgi?id=782175 -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing support for OS/2
Hi, sorry for the delay to reply. My change was performed mechanically without any tests. So, I don't know if the OS/2 widget is actually alive. However, I was requested a review of IME code for OS/2 on this June. https://bugzilla.mozilla.org/show_bug.cgi?id=768742 Therefore, I was thinking that it's alive. On 2013/08/02 8:39, Mike Hommey wrote: CCing the last two persons who submitted patches for OS/2 On Thu, Aug 01, 2013 at 04:13:23PM -0700, Gregory Szorc wrote: We have a number of references to OS/2 throughout the build system and source tree. According to Kyle Huey OS/2 has likely broken since we removed --disable-ipc (bug 638755) in March 2011. While OS/2 is a tier-3 supported build configuration [1], we will shortly be rewriting a bunch of the build rules to handle non-recursive compilation. Since OS/2 is effectively dead as an operating system and since it apparently hasn't been able to build mozilla-central since 2011 without many people complaining AFAIK, I'm proposing that we remove traces of OS/2 from the build system. This likely plays out as not carrying OS/2 support forward as we change things. If the OS/2 community wishes to submit patches to re-add support, we can accept them, just like any tier-3 platform. Just to be clear, I don't believe other tier-3 operating systems may fall victim during refactors. OS/2 is special in that the OS is officially dead and sufficiently different from other supported platforms. It therefore is a non-trivial burden for us to attempt support as we perform large refactors to the build system. Are there any objections to this proposal? Gregory Szorc Build Config Module Owner [1] https://developer.mozilla.org/en-US/docs/Supported_build_configurations ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
nsGUIEvent.h related stuff has been sorted out
Hello. I'd like to share the information about new event related stuff in Gecko. nsGUIEvent.h defined and implemented all events (except nsMutationEvent). Additionally, it's included by a lot of files including some headers. So, this caused changes in the header needing to waste long time for rebuilding Gecko. For fixing this issues, now, nsGUIEvent.h is separated to following files and nsGUIEvent.h has been removed. * widget/BasicEvents.h * widget/ContentEvents.h * widget/MiscEvents.h * widget/MouseEvents. * widget/TextEvents.h * widget/TextRange.h * widget/TouchEvents.h And content/events/public/nsMutationEvent.h is renamed to: * content/events/public/MutationEvent.h These files are exported under mozilla. So, when you need to include some of them, you should write #include like: #include mozilla/BasicEvents.h FYI: BasicEvent.h is included by the other header files. So, you don't need to include if directly if you've already included one of the others. If you need forward declaration of event class or related stuff, you should *not* do it yourself. Instead of that you should add: #include mozilla/EventForwards.h Actual file of it is widget/EventForwards.h which has all event classes' forward declaration and related structs' forward declaration. Additionally, it defines nsEventStatus, mozilla::Modifiers and mozilla::KeyNameIndex. Please don't include mozilla/*Events.h files from header file directly as far as possible! Additionally, the event names have been completely sorted out. See following list for the detail: BasicEvents.h * nsEvent - mozilla::WidgetEvent * nsGUIEvent - mozilla::WidgetGUIEvent * nsInputEvent - mozilla::WidgetInputEvent * nsUIEvent - mozilla::InternalUIEvent ContentEvents.h * nsScriptErrorEvent - mozilla::InternalScriptErrorEvent * nsScrollPortEvent - mozilla::InternalScrollPortEvent * nsScrollAreaEvent - mozilla::InternalScrollAreaEvent * nsFormEvent - mozilla::InternalFormEvent * nsClipboardEvent - mozilla::InternalClipboardEvent * nsFocusEvent - mozilla::InternalFocusEvent * nsTransitionEvent - mozilla::InternalTransitionEvent * nsAnimationEvent - mozilla::InternalAnimationEvent MiscEvents.h * nsContentCommandEvent - mozilla::WidgetContentCommandEvent * nsCommandEvent - mozilla::WidgetCommandEvent * nsPluginEvent - mozilla::WidgetPluginEvent MouseEvents.h * nsMouseEvent_base - mozilla::WidgetMouseEventBase * nsMouseEvent - mozilla::WidgetMouseEvent * nsDragEvent - mozilla::WidgetDragEvent * nsMouseScrollEvent - mozilla::WidgetMouseScrollEvent * mozilla::widget::WheelEvent - mozilla::WidgetWheelEvent TextEvents.h * nsAlternativeCharCode - mozilla::AlternativeCharCode * nsKeyEvent - mozilla::WidgetKeyboardEvent * nsCompositionEvent - mozilla::WidgetCompositionEvent * nsQueryContentEvent - mozilla::WidgetQueryContentEvent * nsSelectionEvent - mozilla::WidgetSelectionEvent TextRange.h * nsTextRangeStyle - mozilla::TextRangeStyle * nsTextRange - mozilla::TextRange * nsTextRangeArray - mozilla::TextRangeArray TouchEvents.h * nsGestureNotifyEvent - mozilla::WidgetGestureNotifyEvent * nsSimpleGestureEvent - mozilla::WidgetSimpleGestureEvent * nsTouchEvent - mozilla::WidgetTouchEvent MutationEvent.h * nsMutationEvent - mozilla::InternalMutationEvent The naming rules of them are: 1. Defined in mozilla namespace. 2. Use prefix Widget or Internal. If the event is dispatched from widget/, use Widget. Otherwise, i.e., generated by content/, layout/ or something others, use Internal. Next, event classes now have vtable. I.e., they have virtual destructor. Therefore, even if you create an instance and stores it in a pointer of its superclass, you don't mind to cast the pointer type to the actual class. For example, WidgetEvent* event = new WidgetKeyboardEvent(...); delete event; is now safe. Finally, the root class, WidgetEvent, has As*Event class. The * doesn't include the prefix. I.e., for WidgetMouseEvent, the method name is WidgetEvent::AsMouseEvent(). This returns the pointer of the instance only when the instance is the class or its derived class. Otherwise, returns nullptr. E.g., WidgetDragEvent is defines as: WidgetEvent +- WidgetGUIEvent +- WidgetInputEvent +- WidgetMouseEventBase +- WidgetMouseEvent +- WidgetDragEvent If an instance is WidgetDragEvent, AsGUIEvent(), AsInputEvent(), AsMouseEventBase(), AsMouseEvent() and AsDragEvent() returns its pointer. The other As*Event() methods return nullptr. You should not use static_cast for Widget*Event and Internal*Event anymore because it may cause wrong casting bug with some mistakes (actually, there was such bug!). I hope this change makes you happy! -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: nsGUIEvent.h related stuff has been sorted out
On 2013/10/26 12:47, Cameron McCormack wrote: Tim Abraldes: So my question is this; is it preferable to keep the As*Event functions, or to use regular C++ casts to accomplish the same behavior? We could use static_cast unconditionally for upcasts, static_cast with a check of |eventStructType| for downcasts to most-derived event types, and dynamic_cast for downcasts to non-most-derived event types. Masayuki Nakano: Please use As*Event() in case #1 and #2. As you said, we can use static_cast since there is eventStructType. However, it's NOT safe because we *might* take mistakes. Actually, there was such bug. If somebody takes mistake, it may cause breaking memory if it sets value to the member. # Anyway, we don't need to do anything in case #3. Additionally, the user code becomes simple since we can avoid checking eventStructType member ;-) Would it make sense to make eventStructType exist only in debug builds, and to assert its value inside the As*Event() functions? I have no idea why you thinks eventStructType should be only in debug build. Unfortunately, eventStructType indicate only only leaf class type. There are NS_SVGZOOM_EVENT and NS_SMIL_TIME_EVENT. These constants are used for WidgetGUIEvent and InternalUIEvent. And when creating DOM event, these values cause creating different DOM event class from NS_GUI_EVENT and NS_UI_EVENT. I think that they should be removed and used message values at creating the events, though. If we can fix above issue, I guess that we can completely hide the member. Then, if we chose to use virtual method for implementing Is*Event(), we can remove it. But I think that it's better to use eventStructType in them since they are called a lot of times. So, non-virtual methods give better performance for us. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Please handle non-printable keys with keydown event handler instead of keypress event handler
Hi, folks. I filed bug 968056 for changing our keypress event behavior for conformance with D3E definition. https://bugzilla.mozilla.org/show_bug.cgi?id=968056 In D3E definition, keypress event shouldn't be fired for non-printable keys like arrow keys, home/end keys, page up/down keys, insert/delete keys, Esc key and Tab key. However, Gecko dispatches keypress event for almost all keys (only except modifier keys like Shift, Ctrl, Alt and Win). In a lot of places of our code, non-printable keys are handled by keypress event handler. We need to change them to keydown event handler for fixing bug 968056. Therefore, I have two requests to you. 1. Please don't handle non-printable keys with keypress event handlers in new code. Please refuse such patch in review process. 2. Please file bugs if you find keypress event handler which handles non-printable key and mark it as blocking bug 968056. Of course, if you fix the new bugs filed for #2, it helps me very much. But it's very helpful to me if you just file bugs for #2. Thanks in advance. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please handle non-printable keys with keydown event handler instead of keypress event handler
On 2014/02/05 16:41, Robert O'Callahan wrote:
Isn't it likely that Web sites depend on the existing behavior too?
I'm not sure until we change the behavior actually.
The D3E spec is defined from behavior of other browsers
(IE/Blink/WebKit/Presto).
So, I believe that there is no problem on cross-browser script.
If there is a problem, it must be like this:
if (navigator.userAgent.indexOf(Firefox) 0) {
// handling non-printable keys with keypress event handler
}
I cannot say there is no such web sites, however, I guess (and hope)
it's minority.
--
Masayuki Nakano masay...@d-toybox.com
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
[Proposal] Move global namespace classes under dom/events to mozilla or mozilla::dom
Hello. A lot of classes under dom/events which were moved from content/events/* are defined in global namespace. However, now, a lot of classes in other modules are defined in mozilla or its descendant namespace. Therefore, *.h files in dom/events need to write type of arguments with full path. It causes a lot of wrap for defining each method due to 80 column per line limitation of our coding rules. So, I'd like to suggest that let's move the classes under dom/events to mozilla or mozilla::dom namespace. Currently, following classes are not in global namespace: * mozilla::dom::DOMWheelEvent * mozilla::dom::EventTarget * mozilla::dom::PointerEvent * mozilla::dom::SpeechRecognitionError * mozilla::dom::Touch * mozilla::InternalMutationEvent * mozilla::TextComposition I'm not sure which is the best name for the classes. E.g., DOMWheelEvent vs. PointerEvent. If we use mozilla::dom namespace for DOM event classes, DOM prefix may be redundant. However, DOM prefix is clearer if its users use using namespace mozilla::dom;. Any ideas? -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Proposal] Move global namespace classes under dom/events to mozilla or mozilla::dom
Hi, On 2014/02/12 23:22, Boris Zbarsky wrote: On 2/12/14 4:46 AM, Masayuki Nakano wrote: I'm not sure which is the best name for the classes. E.g., DOMWheelEvent vs. PointerEvent. I believe in this case PointerEvent is correct, because http://www.w3.org/TR/pointerevents/#pointerevent-interface but DOMWheelEvent should probably be just WheelEvent because https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#interface-WheelEvent In general, the names for things that are standardized should just match the standard name, in the mozilla::dom namespace. In some (rare) cases the standard name starts with DOM; in those situations we should have our name start with DOM as well. Thank you for your reply. It sounds reasonable to me. However, there is a problem. nsDOMEvent will be just Event. And also the header file name will be Event.h. This sounds too general. How do you think about this problem? -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
VK_ENTER has gone
Hi, there were similar two keyCode constants, one was VK_RETURN (DOM_VK_RETURN/NS_VK_RETURN), the other was VK_ENTER (DOM_VK_ENTER/NS_VK_ENTER). These were making a lot of developers confused and event handlers duplicated. Now, VK_ENTER has gone. See bug 969247 for the detail. https://bugzilla.mozilla.org/show_bug.cgi?id=969247 I hope that this doesn't cause any problem. But KeyboardEvent.DOM_VK_ENTER is now undefined in JS code. This might be a big change for some cases. If you find any problems about this change, please file new bugs and mark them as depending on bug 969247. Thanks in advance. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Proposal] Move global namespace classes under dom/events to mozilla or mozilla::dom
On 2014/02/21 20:21, Neil wrote: And also the header file name will be Event.h. Won't it be mozilla/dom/Event.h ? Oh, good point. http://mxr.mozilla.org/mozilla-central/source/dom/events/moz.build#38 38 EXPORTS.mozilla.dom += [ 39 'EventTarget.h', 40 'PointerEvent.h', 41 'Touch.h', 42 ] Now, they are exported as mozilla/dom/*.h. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [Proposal] Move global namespace classes under dom/events to mozilla or mozilla::dom
On 2014/02/12 23:22, Boris Zbarsky wrote: In general, the names for things that are standardized should just match the standard name, in the mozilla::dom namespace. In some (rare) cases the standard name starts with DOM; in those situations we should have our name start with DOM as well. I'd like to want some suggestions about our classes which do NOT represent DOM classes. * nsASyncDOMEvent(derived from nsRunnable) * nsContentEventHandler * nsDOMDataTransfer (?) (derived from nsIDOMDataTransfer) * nsDOMEventTargetHelper (derived from mozilla::dom::EventTarget) * nsEventDispatcher * nsEventListenerManager * nsEventListenerService (derived from nsIEventListenerService) * nsEventStateManager * nsEventStates * nsIMEStateManager * nsJSEventListener (derived from nsIJSEventListener) * nsPaintRequest (derived from nsIDOMPaintRequest) * mozilla::TextComposition Approaches: 1. All of them which don't start with nsDOM are in mozilla. The others in mozilla::dom. However, this approach needs dom:: at some places in nsEventStateManager.h, nsEventListenerManager.h and nsEventDispatcher.h. 2. Some of them which may be used in other modules and not specific classes of represent DOM classes e.g., nsContentEventHandler, nsIMEStateManager and TextComposition are in mozilla (for avoiding dom:: in header files in other modules) and not specific classes about DOM implementation. 3. Or, all of them should be in mozilla::dom. Any ideas? # I like #1 because it's clear rule and non-nsDOM* classes use classes which are defined in other modules (i.e., not in mozilla::dom namespace). -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Guidelines for naming preferences?
Hi, folks. I'm looking for guidelines for naming preferences. However, I've never found it yet. I guess that there is no guidelines. If so, I'd like somebody to create a common guidelines in MDN. When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. I sometimes have trouble about naming a new pref in such situation. A lot of prefs which just switches a feature disabled or enabled are: |foo.a_feature_name| Then, new pref becomes like: |foo.a_feature_name.option| I feel that this is not good especially following case: |foo.a_feature_name| |foo.a_feature_name.disabled_on_some_environments| I think that a pref which enables/disables a feature should end with |.enabled|. Then, above example becomes: |foo.a_feature_name.enabled| |foo.a_feature_name.disabled_on_some_environments| The can be defined by a formula: general-group.(sub-group.)*target-feature.state The state shouldn't be omitted. And also, sub-group should be used as far as possible. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.metricsName| or |ui.colorName|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 This causes a trouble. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. So, I think that they should be named as: ui.system_metrics.int.metricsName ui.system_metrics.float.metricsName ui.system_color.colorName Then, observer never harms performance of other modules. For preventing these unfortunate things, we should define good guidelines about pref names. # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Thanks in advance. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, sub-group should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.metricsName| or |ui.colorName|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
Hi, I wrote a draft of the guideline in MDN roughly. I hope a lot of developers discuss the rules and improve this draft! Thanks in advance. On 2014/06/30 16:24, Masayuki Nakano wrote: Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, sub-group should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.metricsName| or |ui.colorName|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Guidelines for naming preferences?
On 2014/06/30 22:51, Masayuki Nakano wrote: Hi, I wrote a draft of the guideline in MDN roughly. I hope a lot of developers discuss the rules and improve this draft! Oops, the draft is here. Sorry for the spam. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Preferences Thanks in advance. On 2014/06/30 16:24, Masayuki Nakano wrote: Thank you for the reply, but sorry for the delay. On 2014/06/20 23:25, Benjamin Smedberg wrote: On 6/19/2014 10:00 PM, Masayuki Nakano wrote: When I work on some bugs, I need to add a new option for a pref switchable behavior, e.g., if we need to add a new option to a feature and the new one isn't enabled in default settings, it's better to add new pref for the additional option in some cases. Here are the reasons we should be adding prefs: A. We actually want to expose the option in the preference UI (needs UX review) B. To enable release drivers to turn it off easily if there is a problem found C. a feature is experimental and we want to limit it to certain channels while it is stabilized D. To enable other internal usage: e.g. A/B testing via telemetry experiments I believe that we should not be adding hidden prefs just because a small minority of people might want a feature, but we've decided not to expose it in the browser preferences. Those kinds of choices should be made by installing Firefox extensions. In particular, using an extension instead of a hidden pref setting means that we will see the non-default choice in various metrics like about:support, telemetry/FHR, and that Firefox safe mode reverts the setting in case of problems. In any case, this probably doesn't have much to do with naming ;-) There are two hidden prefs. One is not in UI but shown in the list of about:config. The other is not in both UI and about:config. I.g., there is a checking the pref value code but not included in all.js and other similar files. I think that the former is important for some minority users. Yes, they must be minority but their reason to use Firefox must be the customizability by this kind of hidden prefs. And such minority users who can customize about:config may help their friends and family to use our product. Therefore, I believe this is important for keeping market share. The latter should be used for developing or automated tests. And also, sub-group should be used as far as possible. Why? Flat names seem quite reasonable. The reason is for the runtime cost of observing brunches as I mentioned below. nsXPLookAndFeel observes every pref. For doing that, it observes *all* prefs under |ui.|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#430 And the observer uses 3 loops for retrieving the pref cache from the arrays. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#388 If somebody changes a pref under |ui.| at runtime, every change causes running this expensive method. How expensive? Pref changes at runtime are in quite unusual after startup, and I don't think we should necessarily optimize for this case. Although, I don't measure it actually. But if somebody adds a pref under |ui.| and it may be updated from UI, it may cause short hangup at changing it. This is really bad UX and automated tests must not be able to detect this problem. For example, some metrics/colors which can be retrieved with LookAndFeel class can be override by hidden prefs. The most hidden prefs are named as |ui.metricsName| or |ui.colorName|. http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsXPLookAndFeel.cpp#26 # Anyway, if it's allowed, we should rename the pref names referred from nxXPLookAndFeel even though customized users will need to set them again. Do we need this code at all? This sounds like the kind of code that would be better to remove entirely. At least I really need this because these prefs can emulate other environments on each environment. E.g., on Windows, we can test Mac OS X style scrollbar. This is very important to work on around XUL. # FYI: These prefs are not listed in about:config. -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: KeyboardEvent.code attribute
DOM Level 3 Events (D3E) defines an attribute of KeyboardEvent, .code, it allows web applications to check physical key. The specs are: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-motivation https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html The value of .code doesn't depend on selected keyboard layout nor modifier state. The last blocker bug is support of Sun keyboard's legacy keys (We know some Linux users are still using Sun keyboard). https://bugzilla.mozilla.org/show_bug.cgi?id=1020139 Today, this is defined by the newest WD of D3E. Therefore, I'm working on this now. After that, I'd like to enable KeyboardEvent.code in release build too (In non-release builds, already enabled since May, 2014). If we enable this, Gecko is the first engine to support this. Bug to turn on by default in release build: https://bugzilla.mozilla.org/show_bug.cgi?id=1126673 -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to deprecate: nsIDOMWindowUtils.sendKeyEvent()
I'm planing to drop nsIDOMWindowUtils.sendKeyEvent() because: * it's not aware of UI Events' (a.k.a DOM Level 3 Events) KeyboardEvent * nsITextInputProcessor already has new API to synthesize KeyboardEvent via widget * I'm now working on rewriting all mochitests in bug 1134539 (https://bugzilla.mozilla.org/show_bug.cgi?id=1134539) and bug 1134540 (https://bugzilla.mozilla.org/show_bug.cgi?id=1134540) I'm not sure when we'll drop the API actually yet. But this may be important for some add-ons. Therefore, I post this in this stage. Check bug 1134542 for the progress. https://bugzilla.mozilla.org/show_bug.cgi?id=1134542 -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to change UA stylesheet of abbr and acronym (using border-bottom - CSS 3 text-decoration)
HTML5 spec suggests the style of abbr and acronym is:
abbr[title], acronym[title] { text-decoration: dotted underline; }
http://www.w3.org/TR/html5/rendering.html#phrasing-content-0
However, we still use:
abbr[title], acronym[title] { border-block-end: dotted 1px; }
Our style has trouble with some fonts which have large internal leading
and/or external leading (e.g., Meiryo, new Japanese font on Windows
Vista or later). With such fonts, the border-bottom is rendered too far
from the glyphs and may overlap with the next line.
Therefore, we should use the suggested style.
Blink uses same style as our current style. IE doesn't have any special
style for them (i.e., rendered like simple span).
The bug to change the style:
https://bugzilla.mozilla.org/show_bug.cgi?id=1157083
--
Masayuki Nakano masay...@d-toybox.com
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Enabling TSF mode in release builds (Vista or later)
TSF (Text Services Framework) is new API for IME on Windows. And also it supports not only CJK-IME, e.g., speech input system, handwriting system. https://msdn.microsoft.com/en-us/library/windows/desktop/ms629032%28v=vs.85%29.aspx This will be enabled only on Vista or later since TSF on WinXP (and WinServer 2k3) has a lot of problems. Additionally, currently we disable TSF when e10s is enabled since there are some critical bugs to use IME in this mode. This was already enabled in Nightly builds for a long time and in Aurora builds since 38. So, if some critical bugs will be reported, we should disable it before release. The bug to turn on: https://bugzilla.mozilla.org/show_bug.cgi?id=478029 -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit
EventModifierInit is a dictionary to initialize modifier state at creating untrusted event. This allows to initialize AltGraph, CapsLock, Fn, FnLock, Hyper, NumLock, OS, ScrollLock, Super, Symbol and SymboleLock state of creating events and it has been no way to initialize them. Currently, we don't support Super and Hyper modifier state yet. Therefore, we don't support modifierSuper and modifierHyper in this time. Bug to implement: Support D3E EventModifierInit https://bugzilla.mozilla.org/show_bug.cgi?id=1124608 Link to standard: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#h-event-modifier-initializers -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit
On 2015/04/09 16:41, Ms2ger wrote: What are other browsers planning to do? Not sure. We're the first implementer around new KeyboardEvent. Do we have any tests in wpt that could show interop? I think, no. I don't know if tests of DOM Level 3 Events are included in wpt. (of course, mochitest has them, though) -- Masayuki Nakano masay...@d-toybox.com Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing PR_LOG levels
Hi,
I still want a same level as PR_LOG_ALWAYS.
In nsTextStore which is an implementation of ITextStoreACP of TSF uses
PR_LOG_ALWAYS only logs the module behavior. I.e., we can use to check
specific IME behavior with this level. I don't like to call this as
error. And also I wrote some documents how to log IME behavior. For
backward compatibility with such documents, I think that the info
should behave as PR_LOG_ALWAYS. SO, I think that the new enum should be:
enum class LogLevel
{
Disabled = 0, // Logging is disabled for this module
Info,
Error,
Warning,
Debug,
};
--
Masayuki Nakano masay...@d-toybox.com
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Stepping down as the module owner of editor/
At least for now, I don't have much time to work under editor/ except when I need to work on it for fixing IME related bugs. But for that, I've touched some code under editor/ related to event handling. So, I think that it might be possible me to review some patches which changes the event handlers in editor. Although, I'd like to work on editor/ in the future. On 2015/10/22 9:49, Ehsan Akhgari wrote: As some of you may know, nobody has been actively working on the editor module for about 3 years now. I started working on this module about 6 years ago and as the newest and only person working on it, I started to own the Core::Editor module. I've tried to make occasional fixes and review patches in my spare time for the past 3 years, but currently with my other responsibilities I've been unable to even keep up with the occasional patch reviews. I think it's time for me to step down as the owner of editor/. This makes me sad, and I've tried various ways of finding an active contributor for this area of the code but have not had any success. If someone is interested to take this over, please let me know and I will do my best to help you. I am planning to finish my outstanding code reviews by the end of this month. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: sendKeyEvent doesn't support event.key
Yeah, I already documented that in MDN... https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindowUtils#sendKeyEvent%28%29 On 2015/10/27 0:48, smaug wrote: On 10/26/2015 10:21 AM, Amit Zur wrote: MDN says keyCode is deprecated and web developers should favor `key` instead. But sendKeyEvent doesn't support key property on the event. I found bug #1214993 but the solution there is a workaround for the home button for TV. Can we expect this to be fixed any time soon? You probably want to use http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to drop TSF (Text Services Framework) support on WinXP and WinServer 2003
Summary: Drop TSF support only from WinXP and WinServer 2003. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1205600 Platforms: Windows XP, Windows Server 2003 and Windows Server 2003 R2 Estimated or target release: Gecko 44 Background: I've already given up to support TSF on WinXP and WinServer 2003 since the TSF on them are much immature and Natural Input which is Japanese IME bundled on WinXP behaves too much complicated but few users were used. Starting Gecko 41, TSF is enabled in default settings only on Vista or later. For enabling TSF on WinXP or WinServer2k3, user needs to change "intl.tsf.force_enable" to true from about:config. Dropping this feature from WinXP will cause inconvenience to WinXP Tablet users. But I think that such users were already updated their devices to Android Tablet, iPad or newer Windows Tablet. So, it must not be worthwhile to support limited support of TSF on legacy Windows. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Bug 1260651 will rename whole classes under editor/libeditor, so, when you need to touch in it, let me know before landing
Hi, folks, I've written 60 patches for bug 1260651 in this two days. These patches conflict with any changes under editor/libeditor. So, if you need to touch under the directory, please let me know before writing a patch or landing a patch. Ehsan, if you're busy to review for now, let me know. Smaug might be a good reviewer for that. Thanks in advance. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Why do we still need to include Qt widget in mozilla-central?
On 2016/04/12 20:27, Henri Sivonen wrote: On Tue, Apr 12, 2016 at 7:45 AM, Masayuki Nakano <masay...@d-toybox.com> wrote: So, my question is, why do we still have Qt widget in mozilla-central? What the reason of keeping it in mozilla-central? My understanding is that https://git.merproject.org/mer-core/qtmozembed/ still uses it. Yeah, but they can clone m-c to their repository and it must be nicer since Qt widget code is broken in a lot of days under current our management. > As we are figuring out how to be more embeddable (see https://medium.com/@david_bryant/embed-everything-9aeff6911da0 ), it's probably a bad time to make life hard for an existing embedding solution. If we continue to support Qt widget, I'd like we keep Qt widget buildable. At least on mozilla-central and tryserver, building Qt widget everyday will prevent bustage. # My post didn't suggest to drop Qt widget. The status, i.e., dropping or continuing, should be clearer. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Why do we still need to include Qt widget in mozilla-central?
Hello. mozilla-central has dropped a lot of platform supports after Gecko 1.9, especially OS/2 which was contributed by some volunteers. However, there is still Qt widget. Looks like that nobody isn't working on Qt widget but when I reorganizing some code, like WidgetEvent related code, I still need to maintain Qt widget too. However, as far as I know Qt widget cannot be built without errors. Additionally, Qt widget is not implemented fully. For example, IME is never supported on Qt widget. So, my question is, why do we still have Qt widget in mozilla-central? What the reason of keeping it in mozilla-central? -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to drop TSF (Text Services Framework) support on WinXP and WinServer 2003
Done. Will be in 49. On 2015/09/17 18:40, Masayuki Nakano wrote: Summary: Drop TSF support only from WinXP and WinServer 2003. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1205600 Platforms: Windows XP, Windows Server 2003 and Windows Server 2003 R2 Estimated or target release: Gecko 44 Background: I've already given up to support TSF on WinXP and WinServer 2003 since the TSF on them are much immature and Natural Input which is Japanese IME bundled on WinXP behaves too much complicated but few users were used. Starting Gecko 41, TSF is enabled in default settings only on Vista or later. For enabling TSF on WinXP or WinServer2k3, user needs to change "intl.tsf.force_enable" to true from about:config. Dropping this feature from WinXP will cause inconvenience to WinXP Tablet users. But I think that such users were already updated their devices to Android Tablet, iPad or newer Windows Tablet. So, it must not be worthwhile to support limited support of TSF on legacy Windows. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Added --disable-e10s to mach run
Thank you, Xidorn (and of course, arai-san). I'm really happy to test IME with non-e10s mode!! On 2016/07/17 22:48, Xidorn Quan wrote: Hi, In bug 1287069 (https://bugzil.la/1287069), I just landed a new command line argument, --disable-e10s, to |mach run|. As its name indicates, it would run the program with e10s disabled. This argument is effectively identical to setting pref "browser.tabs.remote.force-disable" to true, but as it uses an environment variable to control, no pref would be affected. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 1260651 will rename whole classes under editor/libeditor, so, when you need to touch in it, let me know before landing
Now, the patches are in mozilla-inbound. Following list is old name and new names. This list does NOT include static methods which were in global namespace but are now in mozilla namespace. If you have better suggestion for new names, let me know as soon as possible. AddStyleSheetTxnmozilla::AddStyleSheetTransaction DeleteNodeTxnmozilla::DeleteNodeTransaction DeleteRangeTxnmozilla::DeleteRangeTransaction DocumentResizeEventListenermozilla::DocumentResizeEventListener DOMPointmozilla::EditorDOMPoint EditAggregateTxnmozilla::EditAggregateTransaction EditorInputEventDispatchermozilla::EditorInputEventDispatcher EditTxnmozilla::EditTransactionBase PlaceholderTxnmozilla::PlaceholderTransaction PropItemmozilla::PropItem RemoveStyleSheetTxnmozilla::RemoteStyleSheetTransaction ResizerMouseMotionListenermozilla::ResizerMouseMotionListener ResizerSelectionListenermozilla::ResizerSelectionListener SetDocTitleTxnmozilla::SetDocumentTitleTransaction SetSelectionAfterTableEditmozilla::AutoSelectionSetterAfterTableEdit StyeleCachemozilla::StyleCache TypeInStatemozilla::TypeInState WSTypemozilla::WSType mozilla::dom::AutoReplaceContainerSelNotify mozilla::AutoReplaceContainerSelNotify mozilla::dom::ChangeAttributeTxnmozilla::ChangeAttributeTransaction mozilla::dom::ChangeStyleTxnmozilla::ChangeStyleTransaction mozilla::dom::CreateElementTxnmozilla::CreateElementTransaction mozilla::dom::DeleteTextTxnmozilla::DeleteTextTransaction mozilla::dom::IMETextTxnmozilla::CompositionTransaction mozilla::dom::InsertNodeTxnmozilla::InsertNodeTransaction mozilla::dom::InsertTextTxnmozilla::InsertTextTransaction mozilla::dom::JoinNodeTxnmozilla::JoinNodeTransaction mozilla::dom::SplitNodeTxnmozilla::SplitNodeTransaction nsAutoEditBatchmozilla::AutoEditBatch nsAutoEditInitRulesTriggermozilla::AutoEditInitRulesTrigger nsAutoInsertContainerSelNotifymozilla::AutoInsertContainerSelNotify nsAutoLockListenermozilla::AutoLockListener nsAutoLockRulesSniffingmozilla::AutoLockRulesSniffing nsAutoMoveNodeSelNotifymozilla::AutoMoveNodeSelNotify nsAutoPlaceHolderBatchmozilla::AutoPlaceHolderBatch nsAutoRemoveContainerSelNotifymozilla::AutoRemoveContainerSelNotify nsAutoRulesmozilla::AutoRules nsAutoSelectionResetmozilla::AutoSelectionRestorer nsAutoTrackDOMPointmozilla::AutoTrackDOMPoint nsAutoTxnsConserveSelectionmozilla::AutoTransactionsConserveSelection nsAutoUpdateViewBatchmozilla::AutoUpdateViewBatch nsBaseEditorCommandmozilla::EditorCommandBase nsBoolDomIterFunctormozilla::BoolDomIterFunctor nsBRNodeFunctormozilla::BRNodeFunctor nsClearUndoCommandmozilla::ClearUndoCommand nsCopyAndCollapseToEndCommandmozilla::CopyAndCollapseToEndCommand nsCopyCommandmozilla::CopyCommand nsCopyOrDeleteCommandmozilla::CopyOrDeleteCommand nsCutCommandmozilla::CutCommand nsCutOrDeleteCommandmozilla::CutOrDeleteCommand nsDeleteCommandmozilla::DeleteCommand nsDOMIteratormozilla::DOMIterator nsDOMSubtreeIteratormozilla::DOMSubtreeIterator nsEditorControllermozilla::EditorController nsEditorEventListenermozilla::EditorEventListener nsEditorHookUtilsmozilla::EditorHookUtils nsEditorUtilsmozilla::EditorUtils nsEmptyEditableFunctormozilla::EmptyEditableFunctor nsHTMLCSSutilsmozilla::CSSEditUtils nsHTMLEditormozilla::HTMLEditor nsHTMLEditor::BlobReadermozilla::HTMLEditor::BlobReader nsHTMLEditorEventListnermozilla::HTMLEditorEventListener nsHTMLEditRulesmozilla::HTMLEditRules nsHTMLEditUtilsmozilla::HTMLEditUtils nsHTMLURIRefObjectmozilla::HTMLURIRefObject nsInsertPlaintextCommandmozilla::InsertPlaintextCommand nsInternetCitermozilla::InternetCiter nsPasteCommandmozilla::PasteCommand nsPasteQuotationCommandmozilla::PasteQuotationCommand nsPasteTransferableCommandmozilla::PasteTransferableCommand nsPlaintextEditormozilla::TextEditor nsRangeStoremozilla::RangeItem nsRangeUpdatermozilla::RangeUpdater nsRedoCommandmozilla::RedoCommand nsRulesInfomozilla::RulesInfo nsSelectAllCommandmozilla::SelectAllCommand nsSelectionMoveCommandsmozilla::SelectionMoveCommands nsSelectionStatemozilla::SelectionState nsSwitchTextDirectionCommandmozilla::SwitchTextDirectionCommand nsTableCellAndListItemFunctormozilla::TableCellAndListItemFunctor nsTextEditRulesmozilla::TextEditRules nsTextEditRulesInfomozilla::TextEditRulesInfo nsTextEditUtilsmozilla::TextEditUtils nsTrivialFunctormozilla::TrivialFunctor nsUndoCommandmozilla::UndoCommand nsUuiqueFunctormozilla::UniqueFunctor nsWSRunObjectmozilla::WSRunObject nsWSRunObject::WSFragmentmozilla::WSRunObject::WSFragment nsWSRunObject::WSPointmozilla::WSRunObject::WSPoint nsEditor::CreateTxnForIMEText() mozilla::EditorBase::CreateTxnForComposiiton() -- Masayuki Nakano <masay...@d-toybox.
Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths
Do you have any ideas of the cases we should use Add*VarCache? For example, it's bad if using Get* when: * every painting * every mousemove * every user input except mousemove * every focus move * every DOM change * every page load etc. I wonder, if everybody uses Add*VarCache, doesn't it cause another performance problem when a pref is changed? On 2017/02/22 20:18, smaug wrote: Hi, Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value in some static variable or so. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
What's a good variable name for ErrorResult?
Hi, Variable name for ErrorResult hasn't defined in our coding rules yet: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Error_Variables Do we have a consensus for it? According to m-c's code, I can see some variable names for it: * er * rv/aRv * error/aError * errorResult * err * er * erv * result * res rv/aRv is used in most places, if we won't worry about conflict with nsresult's variable name, taking this makes sense to me. However, I've seen some methods which have both variables for nsresult and ErrorResult. In such case, what names should be used for them? (I usually use erv for consistency with nsresult's naming rule.) Additionally, developers used to believe rv is a variable name for nsresult but currently, it cannot. When you try to build your patch, you may see build error caused by |ErrorResult rv;|. Anyway, I'd like we to add a rule to the coding style guide. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: nsIHTMLEditor.setDocumentTitle()
nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and Composer of SeaMonkey. Additionally, they can set editable document title with |document.title = "foo";|. The only difference of a call of |nsIHTMLEditor.setDocumentTitle()| and |document.title = "foo";| is, nsIHTMLEditor.setDocumentTitle() makes the change undoable. However, only for the method, we need to maintain mozilla::SetDocumentTitleTransaction class. Of course, I don't want to do that without some good reasons. As I explained in bug 1312989 comment 0, I don't think that undoable document title change doesn't make sense for users. Therefore, I suggest to remove supporting undoable document title change in bug 1312989 and nsIHTMLEditor.setDocumentTitle() itself in bug 1312991. https://bugzilla.mozilla.org/show_bug.cgi?id=1312989 https://bugzilla.mozilla.org/show_bug.cgi?id=1312991 Note that I don't want to do them in 52 because 52 will be the next ESR. So, I'd like to do them in 53. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Do we have some documents listing up when we need to touch CLOBBER?
Hi, I'm looking for some documents which explain when we need to touch CLOBBER to avoid build failure. However, I've not found such document yet. I see such information only in CLOBBER about WebIDL change. So, is there any document which lists up when we need to touch CLOBBER? -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: BeforeAftereKeyboardEvent
Due to the end of B2G platform, I'd like to remove mozbrowserbeforekeydown, mozbrowserbeforekeyup, mozbrowserafterkeydown and mozbrowserafterkeyup events and its event classes. They were implemented by bug 989198 [1] for allowing embedded browser elements to override keyboard events [2]. These events have never been enabled on non-B2G platforms but they make the keyboard event propagation complicated especially in PresShell. I'm working on this in bug 1322736 [3]. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=989198 [2] https://wiki.mozilla.org/WebAPI/BrowserAPI/KeyboardEvent#Dispatch_KeyboardEvent_across_BrowserElements [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1322736 -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Who loves multiple selection feature in editor?
At investigating selection API behavior, I realized that non-Gecko engines don't support multiple selection. For example, document.getSelection().addRange(somethingNewRange) does nothing when the selection has a range. You can see the behavior with following testcases: 1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/ 2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/ Personally, I like the multiple selection feature when I copy a lot of fragments of a document. However, who needs this feature in editor? Supporting multiple selection in editor makes our editor code complicated. For example, when web apps try to make the text content bold, editor needs to do it at every selection range. If selection is modified during handling something, loop for selection ranges may cause crash (I've seen a lot of similar crash bugs). So, it might be better to stop supporting multiple selection only in editor if the feature is not so loved by users. I filed a bug for discussing this issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1323681 Feel free to comment anything. Thanks in advance. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Who loves multiple selection feature in editor?
On 2016/12/20 8:00, Mats Palmgren wrote:
On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
> Supporting multiple selection in editor makes our editor code
> complicated.
Why is that so exactly? By necessity, the code already operates
on one Range, right? so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing
code to all the ranges?
That's a good point. Even if we won't remove multiple selection feature
from editor, we should rewrite *all* selection loop with such utility.
> And for functions that doesn't make sense
to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.
Makes sense!
Would that help solve the problem?
I can say "yes" from the point of maintenance cost. But there is another
concern. Other browsers *ignore* Selection.addRange() when there is
already one range in the Selection. So, following code may be
incompatible with other browsers:
onSomething() {
let newRange = document.createRange();
newRange.setStart(foo, bar);
// If rangeCount is 0, the result on Gecko is same as other browsers,
// but not so if selection already has a range.
document.getSelection().addRange(newRange);
// Unexpected range (newRange) will be removed on Gecko, but the
// range may be a bug of web apps, but it won't be found with
// testing other browsers.
document.execCommand("delete");
}
--
Masayuki Nakano <masay...@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Who loves multiple selection feature in editor?
On 2016/12/20 6:21, Jared Wein wrote: We currently use multiple selections for highlighting the domain in the location bar, as well as find-in-page "highlight all". What would you recommend we do if this is removed? I don't see how we would implement "highlight all" without it. I'm suggesting this issue only for normal selection (i.e., nsISelectionController::getSelection(nsISelectionController::SELECTION_NORMAL)). Multiple selection for other selection types are necessary, e.g., SELECTION_SPELLCHECK, SELECTION_IME_RAWINPUT, SELECTION_IME_SELECTEDRAWTEXT, SELECTION_IME_CONVERTEDTEXT, SELECTION_IME_SELECTEDCONVERTEDTEXT and SELECTION_FIND. So, perhaps, you don't need to mind about such feature. (Although, I don't know which selection type is used in location bar.) -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Who loves multiple selection feature in editor?
On 2016/12/17 2:32, Ehsan Akhgari wrote: We currently expose selections with multiple ranges at several levels: * The developer facing APIs. As you have noted above, our selection API allows you to construct and examine multi-range selections. This is something that we should fix at some point, since other browser vendors have been very clear that they won't implement this functionality (and I think that's a good idea) so we're not interoperable with them on this front. * The user facing functionality. Currently we expose multi-range selections to the user in the following ways (perhaps among others that I'm missing?): * Table cell selection (by Ctrl/Cmd-clicking on several table cells allows you to select them all) * Mouse based selection (by holding Ctrl/Cmd when selecting something on a page with another selection present) * (and perhaps touch based selection also similarly, but I don't have a device I can test that on) There is at least one good use case for this, which is copying things to the clipboard, but if we decide to keep the user facing functionality, then we should determine what to expose to developers when a multi-range selection is made by users. There are several options, such as only representing the first selection in the range, or the latest (last) one. (I also wonder how many people even know about these ways to create multi-range selections, given how undiscoverable they are! We should probably add telemetry to measure their usage.) * The interactions with the editor, which I definitely agree is a mess. I'm not sure what you specifically mean by not supporting them. Given that they are currently possible to create by the user, we need to handle them _somehow_ in the editor code. I personally think we should drop support for user made multi-range selections over editable regions to guarantee that the editor code never actually hits this case... My original idea was, to stop supporting multiple selection in editor completely. I.e., users cannot add selection range by mouse operation nor authors cannot add range like other browsers. However, indeed, if user edits table, multiple selection might be useful. Hmm... * Gecko's internal usage of multi-range selections. We use multi-range selections to implement some other selection types, including spellcheck (which we use to mark the misspelled areas to be drawn with the red squiggly line) and find (which we use to mark highlighted areas as the result of using the find bar, which can create a multi-range selection when using the Highlight All mode.) Clearly we can't drop support for what we need to deal with spellcheck selections which are often multi-range. Have you considered this in your plans? I'm talking about only nsISelectionController::SELECTION_NORMAL. Other selections need multiple selection. The reason why our editor code becomes complicated is, multiple normal selection ranges become "edit targets". For example, when you type a character when there are multiple selection ranges, current editor removes all ranges first. Then, inserts the character at first or last range (I forgot which range is focused range). At this time, we need to create loop for deleting all selection ranges, but the ranges may be changed/removed during handling other selection ranges. We don't have any spec how do we behave in such case. I think we should probably ask other browser vendors about this again so that we can plan our future here better. I agree. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Do we have some documents listing up when we need to touch CLOBBER?
Oh, do you mean that nobody doesn't have concrete scenarios when developers need to touch CLOBBER? When not touching CLOBBER causes build failure at autoland, will it be fixed by a follow up landing which touches CLOBBER or backed out and need to reland same patches with touching CLOBBER? If it's the latter, there should be listed up the scenarios in MDN or somewhere. (Although, even if it's the former, such document must be helpful for anybody work on managing the tree.) On 2016/12/17 2:22, Benoit Girard wrote: One of my goal when introducing CLOBBER was to document what was causing us to CLOBBER so that we could audit and fix them if we ever found the time. You can get a pretty good idea by going through the history of the file. I don't believe anyone has taken to time to go through the CLOBBER hg history to find the causes and document them. That could be interesting. On Fri, Dec 16, 2016 at 12:16 AM, Masayuki Nakano <masay...@d-toybox.com> wrote: Hi, I'm looking for some documents which explain when we need to touch CLOBBER to avoid build failure. However, I've not found such document yet. I see such information only in CLOBBER about WebIDL change. So, is there any document which lists up when we need to touch CLOBBER? -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Do we have some documents listing up when we need to touch CLOBBER?
On 2016/12/16 19:53, Mike Hommey wrote: On Fri, Dec 16, 2016 at 05:16:25PM +0900, Masayuki Nakano wrote: Hi, I'm looking for some documents which explain when we need to touch CLOBBER to avoid build failure. However, I've not found such document yet. I see such information only in CLOBBER about WebIDL change. So, is there any document which lists up when we need to touch CLOBBER? The rule is that CLOBBER should never need to be touched. Unfortunately, our build system is far from perfect, and there are plenty of cases where that doesn't actually hold true. There are a bunch of bugs filed for those cases, and new ones should be filed and marked as blocking bug #941904. IOW, the dependencies of bug #941904 that are still open are the currently known cases where a CLOBBER was required, but many of them are of the form "bug # required a clobber". Mike Thank you for the information! That fixes my concern. I thought that platform developers need to touch CLOBBER at writing patches by themselves. So, not necessary us to touch CLOBBER really helps me. -- Masayuki Nakano <masay...@d-toybox.com> Manager, Internationalization, Mozilla Japan. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Is Alt+Shift+F10 a good shortcut key to open context menu forcibly on Windows and Linux?
Gecko supports that user can block web apps to prevent to open the context menu with Shift key. For instance, Shift+Right-Click and Shift+ContextMenu can open the context menu forcibly. Additionally, Shift+F10 is a well-known shortcut key to open context menu. However, this was not working as expected. The Shift state is referred unexpectedly and it always forcibly open the context menu. This bug was fixed by bug 1338369. On the other hand, users cannot open the context menu with Shift+F10 forcibly now and Shift state is necessary for this key combination. Therefore, for a11y, we need to declare other key combination as forcibly opening the context menu. Currently, Alt+Shift+F10 is the best candidate since DevTools use Ctrl+Shift+Foo a lot. Do you have some better idea or know a problem of using this key combination? I'd be happy if you'd let us know your idea. The bug is bug 1347079: https://bugzilla.mozilla.org/show_bug.cgi?id=1347079 Thanks in advance. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove UIEvent.isChar
UIEvent.isChar was (probably) designed for that web apps can distinguish the key combination inputs character(s). However, this is initialized only on macOS (always false on the other platforms) and other browsers don't support this. Unfortunately, Add-on SDK checked this value. Currently, you see garbage code of referring this here: https://dxr.mozilla.org/mozilla-central/rev/f9362554866b327700c7f9b18050d7b7eb3d2b23/addon-sdk/source/lib/sdk/keyboard/hotkeys.js#72 However, nobody refers this variable now. Some existing add-ons have old code of this. They refer the value but fortunately, the behavior after removing this attribute won't be changed because when it's false, they refer keyCode value but the value is always false even with current build except on macOS. So, I'd like to remove this non-standard attribute from Gecko. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1347073 -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to change editor newline behavior
On 4/5/17 9:12 AM, Ehsan Akhgari wrote:> On Tue, Apr 4, 2017 at 11:31 AM, Aryeh Gregor <a...@aryeh.name > <mailto:a...@aryeh.name>> wrote: > > On Tue, Apr 4, 2017 at 5:57 PM, Ehsan Akhgari > <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote: > > I don't own this module any more, so this isn't my call to make, but if > > I had to choose what to do here, I would probably either choose to not > > change our behavior (since I'm not sure what we're gaining here > > concretely -- as AFAIK we're not investing in bringing our behavior on > > par with other engines on a more broad basis with regards to editing), > > Masayuki seems to be in favor of trying to match Blink more. > > > Masayuki's opinion here certainly outweighs mine. :-) Yeah, I like better to make our behavior more compatible with other browsers if the other behavior does make sense (or at least it's not "not makes sense"). Our current market share doesn't have so many impact for web developers. Therefore, I worry about that if we keep compatibility with older Gecko rather than other browsers, new web services would not support Gecko due to the market share vs. implementing cost. > > On the idea of the test plan that Benjamin brought up, I'm not sure what > > to put in such a test plan, due to the issue I mentioned above (it being > > totally non-obvious what the expected breakage of this change would look > > like.) > > We could put the default defaultParagraphSeparator change behind a > pref and leave the pref off on release (or on beta and release?) for > some period and see if we get bug reports. I don't think there's any > way to detect breakage by telemetry, so we'd have to rely on user > reports. > > > This may be a good idea as well. I doubt it partially. In my latest experience, most testers use pre-release bulds silently. I usually get regression reports after reaching risky patch to the release especially when it's limited to non-English users. So, in this case, I think we'd get regression reports of web apps which is used in world wide. Otherwise, we wouldn't get regression reports until releasing the new behavior. # Sorry I posted same message from outside of dev-platform. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Changing default Japanese fonts to modern fonts
Hi,
We decided that we should change our default Japanese fonts from legacy
"MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap
glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho"
(serif).
This has been enabled on Nightly and early Beta since 55 [1].
Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly yesterday
[2]. I.e., the new default settings are enabled on release build
starting from 57.
I'd like to introduce some backgrounds:
"Meiryo" is installed on Vista or later (but not installed on Win10
unless you add Japanese in system language settings). "Yu Gothic" and
"Yu Mincho" is installed on Win8.1 or later.
Both Edge and Chrome already started to use "Meiryo" as their default
Japanese fonts. So, using "Meiryo" improves the compatibility between
browsers and just looks better and is easier to read than bitmap glyph.
One of the reason why we didn't use "Meiryo" as default fonts is,
"Meiryo" has normal style glyph as italic style glyph. E.g.,
|abc| looks like |abc|, not |a/b/c|. The other browsers have this
issue, but I see many users who complain about this issue. For solving
this issue, we added a hack to ignore italic style family of "Meiryo" at
loading fonts [3]. So, now, Gecko is the only one engine which supports
italic style Japanese text with default fonts!
On the other hand, there are still some problems.
"Meiryo" has too big internal leading for supporting accent marks of
Western languages. This causes increasing normal line height than other
fonts. Additionally, Gecko's normal line height computation is not same
as the other browsers. Therefore, this may cause compatibility issue
with the other browsers. For example, our allows to scroll its
content. Therefore, if user drags text in vertically, the text
may be scrolled [4].
If we could use "Yu Gothic" as Japanese default font, it'd be really
nicer except compatibility with the other browsers because it has nicer
glyph than "Meiryo" ("Meiryo" was designed for UI, not for document.
Therefore, it was designed as easier to read even if the font size is
small) and does not have too big leading like "Meiryo". However, there
is a big problem. Text renderer of Windows has a bug. Text of "Yu
Gothic" is rendered as too light [5]. So, the contrast between text and
background color may not be enough for some users. Therefore, currently,
we use "Yu Gothic" as a fallback font only when "Meiryo" isn't available.
Anyway, I believe that this makes 57 look nicer for Japanese users!
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
You don't need to use nsIEditor, nsIPlaintextEditor and nsIHTMLEditor in most places of native code
Hi,
I was working on making editor users use concrete classes rather than
interface classes in a couple of weeks.
As I posted 2 months ago, editor concrete classes are now
mozilla::EditorBase, mozilla::TextEditor and mozilla::HTMLEditor (old
names are nsEditor, nsPlaintextEditor and nsHTMLEditor). Their header
files were already exposed. However, some users kept treating editors
with nsIEditor, nsIPlaintextEditor and nsIHTMLEditor interfaces because
they can be implemented with JS. Fortunately, we succeeded to make them
to builtinclasses [1]. So, you don't need to treat editors with
interfaces anymore in native code.
So, please do not use nsI*Editor anymore in new code. Please use
EditorBase, TextEditor or HTMLEditor classes directly. Then, you can
call non-virtual methods of editors and get the result as return value
instead of out param.
However, there is an exception. If you need to write scriptable method
which gets/sets editor from/to JS, you still need to use nsI*Editor.
When type of pointer is nsIEditor, you can retrieve pointer to concrete
classes easily and safely:
NS_IMETHODIMP
Foo::DoSomething(nsIEditor* aEditor)
{
// EditorBase is base class of any type of editors.
// However, perhaps, you don't need to use this type.
EditorBase* editorBase = aEditor->AsEditorBase();
// TextEditor is plaintext editor class and super class of
// HTMLEditor. This won't be nullptr.
TextEditor* textEditor = aEditor->AsTextEditor();
// HTMLEditor is a subclass of TextEditor. If the instance
// is an HTMLEditor, this returns non-nullptr. Otherwise, i.e.,
// it's a TextEditor instance, returns nullptr.
HTMLEditor* htmlEditor = aEditor->AsHTMLEditor();
...
}
If type of pointer is nsIPlaintextEditor or nsIHTMLEditor, you need to
QI to nsIEditor first. So, if you need to add new scriptable method
which treat editor, using nsIEditor is better than other editor
interfaces since QI cost is not so cheap.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1060051
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: MozPhonetic.phonetic (HTMLInputElement.phonetic) and nsIPhonetic
MozPhonetic has an attribute, phonetic, whose type is DOMString. This is available only in chrome. https://searchfox.org/mozilla-central/rev/224cc663d54085994a4871ef464b7662e0721e83/dom/webidl/HTMLInputElement.webidl#220-224,227 Its XPCOM implementation is nsIPhonetic, which is inherited by EditorBase and HTMLInputElement. https://searchfox.org/mozilla-central/rev/224cc663d54085994a4871ef464b7662e0721e83/dom/html/nsIPhonetic.idl Nobody (including add-ons) uses them now. So, we can get rid of them. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1363278 -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: nsIEditorIMESupport
nsIEditorIMESupport is an empty interface. Members were moved to nsIEditor and nsIEditorIMESupport was made a subclass of it. This interface is now completely unused. So, it should be removed from the tree completely. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325281 -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using references vs. pointers in C++ code
I like using reference to argument if it's non-nullable. In Core::Editor module, such arguments are already replaced with reference in a lot of places. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using the accesskey attribute with HTML elements in browser chrome
On 6/20/2017 5:28 AM, Brian Grinstead wrote: I was wondering what would need to be done in order to use the accesskey attribute on HTML elements in the browser chrome. Here are some of the differences between the attribute in HTML and XUL that I've found so far: 1) In XUL (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/accesskey) the shortcut is `Control + key` on Windows and `Command + key` on Mac. Wow, the document is wrong. Ctrl+foo or Cmd+foo are usually called as "shortcut key" which are different from "access key". On Windows, chrome's access key works with Alt. In HTML (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey) the shortcut is `Alt + Shift + key` on Windows and `Control + Alt + key` on Mac. Yes, this is right. Would we want to change the HTML shortcut (in browser chrome) to match XUL behavior? So, I'm not sure if you are talking about access key or shortcut key here. But I guess, you're talking about access key. Then, it depends on the type of DocShell (chrome vs. content). So, not related to the file type. E.g., we have this bug: https://bugzil.la/349943 2) The FAQ & Policies page (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/XUL_Accesskey_FAQ_and_Policies) conflicts the with previous point when it says that accesskey is only available on Mac in HTML. If this is correct, would we want to disable accesskey functionality on Mac for HTML (in browser chrome) to maintain the current behavior, or would it working be a benefit of using HTML? On macOS, native UI doesn't have access key. Therefore, we don't support it only on macOS. 3) The formatting / underlining is controlled by the label-control xbl binding at http://searchfox.org/mozilla-central/source/toolkit/content/widgets/text.xml#66. Presumably this is something that would need to be reimplemented for HTML elements in order to use them in the browser chrome. Yes. Underlining access key's character needs additional hack. I have no idea how to implement it easily in HTML. Perhaps, capsuling with Shadow DOM? -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder on Try usage and infrastructure resources
I tried to say different point. See the treehearder log, mochitests
didn't run except on Win7 Debug, Android 4.3 API16+ Opt/Debug. So, try
syntax parser or something is really broken. I often meet this kind of bug.
On 9/15/2017 10:07 AM, Kris Maglione wrote:
Your best bet is probably to use `mach try` with a specific set of test
directories. It will generate a set of --try-test-paths flags to
restrict tests to those paths, and only run the first chunk of any
group. Without that, groups shift around too much to be reliable.
On Fri, Sep 15, 2017 at 10:03:00AM +0900, Masayuki Nakano wrote:
Even when I got the chunk numbers, specifying chunk numbers of
mochitests wouldn't work, see this log:
https://treeherder.mozilla.org/#/jobs?repo=try=c09c7046ed0664e89f7224e1de5219c39c94c948
After that, I needed to rerun mochitests with |-u mochitests|. IIRC, I
tried to kick the specific chunks with "Add new jobs", but didn't work.
And also, when I try to investigate random oranges which are not
reproducible on my environments, I want an option like
|--run-until-failure| and |--repeat REPEAT| in the try syntax. Because
of no such options, I need to trigger a lot of jobs manually and that
may/might cause too many oranges.
On 9/15/2017 1:21 AM, Kyle Lahnakoski wrote:
You can try ActiveData, which stores all test results from the past few
weeks. Here is an example query that shows the chunk number for each
run/build combo in the past day. ActiveData is sometimes more than a
day behind
https://activedata.allizom.org/tools/query.html#query_id=4HHuBgDu
{
"from":"unittest",
"select":[
{"aggregate":"count"},
{"value":"action.start_time","aggregate":"max"}
],
"groupby":[
"run.suite",
"run.chunk",
"result.test",
"build.platform",
"build.type",
"run.type"
],
"where":{"and":[
{"eq":{"build.branch":"mozilla-inbound"}},
{"prefix":{"run.suite":"moch"}},
{"gt":{"action.start_time":{"date":"today-day"}}},
{"regex":{"result.test":".*browser_623779.js.*"}}
]},
"limit":1000
}
On 2017-09-14 11:49, Michael de Boer wrote:
On 14 Sep 2017, at 17:48, Marco Bonardo <mbona...@mozilla.com> wrote:
When I need to retrigger a mochitest-browser test multiple times (to
investigate an intermittent), often I end up running all the
mochitest-browser tests, looking at every log until I find the chunk
where the test is, and retrigger just that chunk. The chunk number
changes based on the platform and debug/opt, so it's painful.
Is there a way to trigger only the chunk that will contain a given
test, so I can save running all of the other chunks?
This! This! This! I’d love to be able to do this - would making
testing possible test failure fixes sooo much easier.
Cheers,
Mike.
--
Masayuki Nakano <mnak...@mozilla.com>
Software Engineer, Mozilla
--
Masayuki Nakano <mnak...@mozilla.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder on Try usage and infrastructure resources
Even when I got the chunk numbers, specifying chunk numbers of
mochitests wouldn't work, see this log:
https://treeherder.mozilla.org/#/jobs?repo=try=c09c7046ed0664e89f7224e1de5219c39c94c948
After that, I needed to rerun mochitests with |-u mochitests|. IIRC, I
tried to kick the specific chunks with "Add new jobs", but didn't work.
And also, when I try to investigate random oranges which are not
reproducible on my environments, I want an option like
|--run-until-failure| and |--repeat REPEAT| in the try syntax. Because
of no such options, I need to trigger a lot of jobs manually and that
may/might cause too many oranges.
On 9/15/2017 1:21 AM, Kyle Lahnakoski wrote:
You can try ActiveData, which stores all test results from the past few
weeks. Here is an example query that shows the chunk number for each
run/build combo in the past day. ActiveData is sometimes more than a
day behind
https://activedata.allizom.org/tools/query.html#query_id=4HHuBgDu
{
"from":"unittest",
"select":[
{"aggregate":"count"},
{"value":"action.start_time","aggregate":"max"}
],
"groupby":[
"run.suite",
"run.chunk",
"result.test",
"build.platform",
"build.type",
"run.type"
],
"where":{"and":[
{"eq":{"build.branch":"mozilla-inbound"}},
{"prefix":{"run.suite":"moch"}},
{"gt":{"action.start_time":{"date":"today-day"}}},
{"regex":{"result.test":".*browser_623779.js.*"}}
]},
"limit":1000
}
On 2017-09-14 11:49, Michael de Boer wrote:
On 14 Sep 2017, at 17:48, Marco Bonardo <mbona...@mozilla.com> wrote:
When I need to retrigger a mochitest-browser test multiple times (to
investigate an intermittent), often I end up running all the
mochitest-browser tests, looking at every log until I find the chunk
where the test is, and retrigger just that chunk. The chunk number
changes based on the platform and debug/opt, so it's painful.
Is there a way to trigger only the chunk that will contain a given
test, so I can save running all of the other chunks?
This! This! This! I’d love to be able to do this - would making testing
possible test failure fixes sooo much easier.
Cheers,
Mike.
--
Masayuki Nakano <mnak...@mozilla.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
How to get pretty stack trace on Linux?
I'd like to get pretty stack trance which shows method names rather than only address with tryserver build on Linux. However, nsTraceRefcnt::WalkTheStack() cannot get method names on Linux as you know. The reason why I need to get it is, I have a bug report which depends on the environment and I cannot reproduce it on my any environments. Therefore, I'd like the reporter to log the stack trace when it occurs with MOZ_LOG. My questions are, how to or is it possible to get pretty stack trace on Linux with MOZ_LOG? And/or do you have better idea to get similar information to check which path causes a bug. If it's impossible, I'll create a tryserver build with each ancestor caller logs the path, though. Thanks in advance. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to get pretty stack trace on Linux?
On 10/14/2017 12:29 AM, Masayuki Nakano wrote: Ted, really sorry for the delay to say "Thank you" because of too busy of my life. I tried to do this on my environment (Ubuntu), then, I succeeded to get a pretty stack trace even from trysever build. 1. Put |#include "nsTraceRefcnt.h"| and |nsTraceRefcnt::WalkTheStack(stderr);| where I want to get stack trace. 2. Post it to tryserver. 3. Get Linux build from "B" of "target.tar.bz2" in treeherder. 4. Get build symbols from "B" of "target.crashreporter-symbols.zip" in treeherder. 5. Then, extract all of them. 6. Run the tryserver build from terminal. 7. Save stack trace to a text file. 8. Run |/tools/rb/fix_linux_stack.py < stack.txt| #8 runs in the directory which target.crashreporter-symbols.zip is unzipped. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to get pretty stack trace on Linux?
Ted, really sorry for the delay to say "Thank you" because of too busy of my life. I tried to do this on my environment (Ubuntu), then, I succeeded to get a pretty stack trace even from trysever build. 1. Put |#include "nsTraceRefcnt.h"| and |nsTraceRefcnt::WalkTheStack(stderr);| where I want to get stack trace. 2. Post it to tryserver. 3. Get Linux build from "B" of "target.tar.bz2" in treeherder. 4. Get build symbols from "B" of "target.crashreporter-symbols.zip" in treeherder. 5. Then, extract all of them. 6. Run the tryserver build from terminal. 7. Save stack trace to a text file. 8. Run |/tools/rb/fix_linux_stack.py < stack.txt| Thank you very much! On 9/22/2017 9:55 AM, Ted Mielczarek wrote: On Thu, Sep 21, 2017, at 08:51 PM, Masayuki Nakano wrote: I'd like to get pretty stack trance which shows method names rather than only address with tryserver build on Linux. However, nsTraceRefcnt::WalkTheStack() cannot get method names on Linux as you know. The reason why I need to get it is, I have a bug report which depends on the environment and I cannot reproduce it on my any environments. Therefore, I'd like the reporter to log the stack trace when it occurs with MOZ_LOG. My questions are, how to or is it possible to get pretty stack trace on Linux with MOZ_LOG? And/or do you have better idea to get similar information to check which path causes a bug. If it's impossible, I'll create a tryserver build with each ancestor caller logs the path, though. Hi Masayuki, Our test harnesses accomplish this by piping the output of Firefox through one of the stack fixing scripts in tools/rb[1]. fix_linux_stack.py uses addr2line, which should at least give you function symbols on Nightly. You could use my GDB symbol server script[2] to fetch the actual debug symbols from the symbol server if you want full source line information. Regards, -Ted 1. https://dxr.mozilla.org/mozilla-central/source/tools/rb 2. https://gist.github.com/luser/193572147c401c8a965c ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Changing default Japanese fonts to modern fonts
Ah, yes, this change is only on Windows (only on Windows, we still use
legacy Japanese fonts as default settings).
FYI: We still need to keep using legacy "MS Gothic" font for default
Japanese monospace font since Windows doesn't have modern monospace font.
On 8/24/2017 7:47 AM, ISHIKAWA,chiaki wrote:
Hi,
I use firefox under Windows most of the time, and so it will be very nice.
But obviously this is only for Windows platform, and
does not affect linux or OSX versions. Correct?
On 2017/08/23 14:19, Masayuki Nakano wrote:
Hi,
We decided that we should change our default Japanese fonts from
legacy "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have
bitmap glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu
Mincho" (serif).
This has been enabled on Nightly and early Beta since 55 [1].
Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly
yesterday [2]. I.e., the new default settings are enabled on release
build starting from 57.
I'd like to introduce some backgrounds:
"Meiryo" is installed on Vista or later (but not installed on Win10
unless you add Japanese in system language settings). "Yu Gothic" and
"Yu Mincho" is installed on Win8.1 or later.
Both Edge and Chrome already started to use "Meiryo" as their default
Japanese fonts. So, using "Meiryo" improves the compatibility between
browsers and just looks better and is easier to read than bitmap glyph.
One of the reason why we didn't use "Meiryo" as default fonts is,
"Meiryo" has normal style glyph as italic style glyph. E.g.,
|abc| looks like |abc|, not |a/b/c|. The other browsers have
this issue, but I see many users who complain about this issue. For
solving this issue, we added a hack to ignore italic style family of
"Meiryo" at loading fonts [3]. So, now, Gecko is the only one engine
which supports italic style Japanese text with default fonts!
On the other hand, there are still some problems.
"Meiryo" has too big internal leading for supporting accent marks of
Western languages. This causes increasing normal line height than
other fonts. Additionally, Gecko's normal line height computation is
not same as the other browsers. Therefore, this may cause
compatibility issue with the other browsers. For example, our
allows to scroll its content. Therefore, if user drags text in
vertically, the text may be scrolled [4].
If we could use "Yu Gothic" as Japanese default font, it'd be really
nicer except compatibility with the other browsers because it has
nicer glyph than "Meiryo" ("Meiryo" was designed for UI, not for
document. Therefore, it was designed as easier to read even if the
font size is small) and does not have too big leading like "Meiryo".
However, there is a big problem. Text renderer of Windows has a bug.
Text of "Yu Gothic" is rendered as too light [5]. So, the contrast
between text and background color may not be enough for some users.
Therefore, currently, we use "Yu Gothic" as a fallback font only when
"Meiryo" isn't available.
Anyway, I believe that this makes 57 look nicer for Japanese users!
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)
From some users who use legacy mice which supports only vertical wheel, we have a request to support horizontal scroll with vertical wheel operation with a modifier. https://bugzilla.mozilla.org/show_bug.cgi?id=143038 Now, legacy add-ons have gone since 57 and it may be difficult to override default action of wheel events with WebExtensions, it is the time to support horizontal scroll with vertical wheel operation with Shift key. This will be enabled in default settings except on macOS. The reason why we don't need to use this feature on macOS is, macOS generates horizontal wheel event if user uses legacy mouse and pressing Shift key. And default action of wheel with Alt key is changed to history navigation which is default action of wheel with Shift key in current release build. So, now, we have consistent behavior between Firefox for macOS and the others. Note that this feature won't be exposed to attributes of "wheel" events. This is just a default action change and same behavior as Chrome. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: New default action, horizontal scroll, of wheel with Shift key (except Firefox for macOS)
On 10/18/2017 4:08 PM, Jet Villegas wrote: That is, do I owe you another steak? :-) Always welcome another steak :-D -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: New AltGr key behavior on Windows
Google suggested that browsers shouldn't set ctrlKey and altKey to true
for keyboard events during AltGr key is pressed on Windows. We will
follow the new behavior for compatibility with Chromium and better
accessibility for some language users.
https://github.com/w3c/uievents/issues/147
Background: On Windows, AltGr key is mapped to AltRight key by some
keyboard layouts. However, Windows represents AltGraph state with both
Control and Alt modifier states. For example, if user cannot use
AltRight key (e.g., there is no AltRight key), user can emulate it with
pressing both Ctrl and Alt keys. Another example, when user presses
AltGr key, ControlLeft keydown and AltRight keydown are fired, and when
user releases it, CtrlLeft keyup and AltRight keyup are fired.
Firefox, Chrome and Edge set ctrlKey and altKey to true when
getModifierState("AltGraph") returns true. However, web apps cannot
distinguish whether given keydown event will input some characters
strictly. So, if both ctrlKey and altKey are set to false when user
types some character(s) even with AltGr key, the keys won't be handled
as shortcut key on the web apps. The new behavior improves
accessibility of users who use keyboard layout which has AltGr key,
especially when they use different locale's web apps.
When user presses a key with AltGr key to input a character, Gecko has
dispatched:
1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltRight whose ctrlKey and altKey are true and
getModifierState("AltGraph") returns true.
3. keydown for the key whose ctrlKey and altKey are true and
getModifierState("AltGraph") returns true.
4. keypress for the key whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are true and
getModifierState("AltGraph") returns true.
6. keyup for ControlLeft whose altKey is true.
7. keyup for AltRight (currently, this is not fired due regression of
e10s <https://bugzilla.mozilla.org/show_bug.cgi?id=1435717>)
This becomes:
1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltRight whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns true.
3. keydown for the key whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns true.
4. keypress for the key whose ctrlKey and altKey are false and
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns true.
6. keyup for ControlLeft whose altKey is *false* but
getModifierState("AltGraph") returns *true*.
7. keyup for AltRight
Additionally, KeyboardEvent.key value for AltRight key becomes
"AltGraph" instead of "Alt" (but KeyboardEvent.keyCode won't be changed
for backward compatibility).
When user types a character with emulating AltGr with ControlLeft and
AltLeft keys:
1. keydown for ControlLeft whose ctrlKey is true.
2. keydown for AltLeft whose ctrlKey and altKey are *true* and
getModifierState("AltGraph") returns *false*.
3. keydown for the key whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns *true*.
4. keypress for the key whose ctrlKey and altKey are false and
getModifierState("AltGraph") returns true.
5. keyup for the key whose ctrlKey and altKey are *false* and
getModifierState("AltGraph") returns true.
6. keyup for ControlLeft whose altKey is *true* and also
getModifierState("AltGraph") returns *false*.
7. keyup for AltRight
If the key produces no character when emulating AltGr key press with
Ctrl and Alt keys, its keydown and keyup event's ctrlKey and altKey are
set to *true* and getModifierState("AltGraph") returns false.
In other words, if user emulates AltGr key, only printable key's events
are changed. So, when a key does not input any characters with AltGraph
state, the key combinations can be handled as shortcut keys. Although
any web apps and extensions shouldn't use Control - Alt combination for
shortcut keys at least on Windows.
Note that if active keyboard layout does not have AltGr key,
getModifierState("AltGraph") always returns false (even if both Ctrl and
Alt are pressed).
The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=900750
Target: Firefox 62 or 63.
Chrome has started to release new behavior with 67. And starting from
68, they will switch this behavior permanently.
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Please stop using keypress event to handle non-printable keys
Hello, everyone. Please stop using keypress event for handling non-printable keys in new code when you write new code and new automated tests. Firefox will stop dispatching keypress events for non-printable keys for conforming to UI Events and struggling with web compatibility. (non-printable key means key combination which won't cause inputting character, e.g., arrow keys, backspace key and Ctrl (and/or Alt) - "A" key, etc.) You can perhaps just use keydown event instead. KeyboardEvent.key and KeyboardEvent.keyCode of non-printable key events are always same. Difference between keydown event and keypress event is KeyboardEvent.charCode of printable keys (and Ctrl/Alt + printable keys). So, when you need to use only key or keyCode, please use keydown event. Otherwise, when you need to use charCode, please keep using keypress event. Background: We need to fix bug 968056 (*1) for web-compat issues. Currently, Firefox dispatches keypress events for any keys except modifier keys. This is traditional behavior from Netscape Navigator. However, this is now invalid behavior from a point of view of standards (*2). I'm going to start to work on the bug from next week. However, this requires to rewrite too many keypress event handlers in our internal code and our automated tests. So, please stop using keypress event when you want to handle non-printable keys at least in new code. Thanks in advance. 1: https://bugzilla.mozilla.org/show_bug.cgi?id=968056 2: https://w3c.github.io/uievents/#legacy-keyboardevent-event-types -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: some methods of nsIEditActionListener or the interface itself
I'd like to remove unnecessary methods of nsIEditActionListener or nsIEditActionListener itself completely. This is not buildinclass. So, this can be implemented by XUL addons. Currently, this is used only by ThunderHTMLedit (only Did*()). Additionally, 3 internal classes of Gecko implements this interface. Supporting this interface is expensive from a point of view of Quantum Flow. When editor changes DOM tree, a set of methods of this interface is always called every time. When running for loop to call a method of the interface, we need to copy edit action listeners array with array of strong pointer. Then, we need to call them with nsIDOM* interfaces. I.e., a lot of unnecessary QIs are required. Additionally, each implementation will QI back to nsINode or something. Finally, all of them are virtual call but our internal classes implements less than half of the methods. So, my current idea is, keep supporting ThunderHTMLedit as far as possible. Even with that, we can make all our internal classes are notified directly instead of via the interface. This is not so beautiful but we can get rid of virtual call cost, unnecessary method calls and unnecessary QIs. Then, only XUL addon for Thunderbird may use the interface. However, in most environment, that's not used. So, our editor can check before doing for loop if there is edit action listeners. Feel free to suggest something in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1429676 And currently, I'm working on making HTMLEditRules not derived from nsIEditActionListener: https://bugzilla.mozilla.org/show_bug.cgi?id=1430021 And nsIEditActionListener::Will*() will be removed because of no users: https://bugzilla.mozilla.org/show_bug.cgi?id=1430319 -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to remove: nsIDOMWindowUtils.sendKeyEvent() and nsIFrameLoader.sendCrossProcessKeyEvent()
Hi, I'd like to remove legacy API to dispatch keyboard events. One is nsIDOMWindowUtils.sendKeyEvent(), this has already replaced completely with nsITextInputProcessor [*1] since 2015 [*2]. It's really easy to rewrite legacy API users with new API because our EventUtils.js for mochitest has a good wrapper for using new API [*3]. The other is nsIFrameLoader.sendCrossProcessKeyEvent(). This was implemented for old Fennec [*4] and looks like that nobody uses this API now. This shares same implementation with nsIDOMWindowUtils.sendKeyEvent() but dispatches keyboard events only in the remote process associated with the frame loader. Unfortunately, we don't have alternative API for this. However, if the remote process has focus, keyboard events synthesized with nsITextInputProcessor are sent to the remote process. So, I guess that we don't need this API anymore. I'm working on this at bug 1134542: https://bugzilla.mozilla.org/show_bug.cgi?id=1134542 Thunderbird still uses nsIDOMWindowUtils.sendKeyEvent(). Therefore, I'll wait to land the removing patch until those bugs [*5][*6] are fixed. However, if they won't be fixed by the next weekend, I'll drop these legacy API soon anyway. *1 https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl *2 https://bugzilla.mozilla.org/show_bug.cgi?id=917322 *3 https://searchfox.org/mozilla-central/rev/97cb0aa64ae51adcabff76fb3b5eb18368f5f8ab/testing/mochitest/tests/SimpleTest/EventUtils.js#835-905 *4 https://bugzilla.mozilla.org/show_bug.cgi?id=553149 *5 https://bugzilla.mozilla.org/show_bug.cgi?id=1433648 *6 https://bugzilla.mozilla.org/show_bug.cgi?id=1434317 -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to enable as default paragraph separator of contenteditable/designMode editor by default
Starting from Firefox 60, I'd like to enable as default paragraph
separator of contenteditable/designMode editor by default even in
release channel.
When user typing Enter key in editing host (or body in designMode),
Firefox 59 and earlier insert element. However, the other browsers
insert element (and wraps current line with too). This is
declared by execCommand spec (Unofficial draft):
https://w3c.github.io/editing/execCommand.html#the-insertparagraph-command
We've already enabled this behavior on Nightly and Early Beta since
Firefox 55:
https://bugzilla.mozilla.org/show_bug.cgi?id=1297414
And now, we don't have confirmed regression reports which we haven't
worked on. Additionally, once we use same behavior with the other
browsers in this major difference, new web services could becomes not
supporting our current behavior. That means ESR users may become not to
be able to use such web services. Therefore, I'd like to enable this
before shipping ESR 60.
The bug is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1430551
Note that even if some web services have trouble with new our behavior,
they can take the old behavior with inserting this line:
document.execCommand("defaultParagraphSeparator", false, "br");
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to enable as default paragraph separator of contenteditable/designMode editor by default
On 2/15/2018 5:40 AM, Jet Villegas wrote:
SGTM. Please follow up to make sure this workaround makes it on to MDN:
document.execCommand("defaultParagraphSeparator", false, "br");
Thx!
Hi, Jet-san, I updated the document in MDN:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content#Differences_in_markup_generation
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default
We put off to change this until we get enough telemetry data.
Now, we have a lot of data in Beta 62 users. That indicates that each
specific UI is rarely shown (< 0.5% of all HTMLEditor instances).
However, according to operation count per HTMLEditor instance, some of
them may be used by only a few users intentionally.
Currently, I plain:
- 63 disables the UIs by default only on Nightly and Early Beta.
- 64 disables the UIs by default on all channels.
Then, we'll provide new prefs to enable them by default forcibly. This
allows us to collect telemetry data from testers even before web apps
enable the UIs with execCommand explicitly.
If we'll get new telemetry data of 62 Release and it indicates we
shouldn't change our behavior, we should cancel the changes before
shipping the 64 release.
See the detail of current telemetry result here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1452538#c19
On 2018/04/05 15:58, Masayuki Nakano wrote:
This incompatibility is pointed by W3C's Editing API WG:
https://github.com/w3c/editing/issues/171
Gecko has some specific editing UI of HTML editor.
1. Resiziers of , , absolute positioned elements.
2. Adding new table row/column from buttons.
3. Removing existing table row/column from buttons.
4. Grabber to move absolute positioned element.
Currently, all of those UIs are not implemented by the other browsers.
However, they are available in Gecko by default.
Therefore, web app developers need to disable those features with:
document.execCommand("enableObjectResizing",
false, false); // #1
document.execCommand("enableInlineTableEditing",
false, false); // #2 and #3
So, if web apps don't call them, only Firefox users can modify or
elements as unexpected for their developers.
Additionally, web apps cannot disable only #4.
So, for solving this incompatibility issue, we should:
* Disable those UI by default
* But allow to enable those UI for backward compatibility
* Add new command "enableAbsolutePositionEditing" command for allowing
to enable #4
I'm working on this incompatibility issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to unship "namedanchor" keyword from nsIHTMLEditor.createElementWithDefaults(), nsIHTMLEditor.getSelectedElement() and nsIHTMLEditor.getElementOrParentByTagName()
nsIHTMLEditor::CreateElementWithDefaults(), nsIHTMLEditor::GetSelectedElement() and nsIHTMLEditor::nsIHTMLEditor::GetElementOrParentByTagName() treat "namedanchor" as element. However, it seems that this is legacy name since there is another name, "anchor", and only "anchor" is used in comm-central and BlueGriffon. Due to not defined as an Atom, it does not make sense to keep supporting this value. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1484092 The first release of this change will be 63. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default
On 4/7/2018 12:39 AM, Ehsan Akhgari wrote: On Thu, Apr 5, 2018 at 11:08 PM Masayuki Nakano <masay...@d-toybox.com <mailto:masay...@d-toybox.com>> wrote: On 4/6/2018 2:50 AM, Ehsan Akhgari wrote: > Hi Masayuki, > > First of all, thank you for taking on this task. I have a few questions. > > * What does the backwards compatibility story for these changes look > like? Would we end up for example throwing exceptions or returning a > different value from execCommand/queryCommandState/etc for one of the > existing two commands? If there are any backwards compatibility > concerns, what are your plans for them? Note that these two commands > are extremely popular in existing code that knows about Gecko (since it > typically has to start off by disabling this UI as you've noted.) It *might* be possible that a few web apps (including intranet only apps) may allow users to resize some elements, edit table structure and/or move absolute positioned elements with these built-in UI only on Firefox. If such apps actually exist, they can enable the Gecko specific UI explicitly with using execCommand. Then, we can collect actual usage with telemetry. If such apps don't use execCommand to explicitly enable these commands, they will be breaking with this change, wouldn't they? Yes, it is, of course. If we are interested in knowing about whether this is a problem, there's the possibility of collecting telemetry beforehand too. For example, we can collect telemetry upon the usage of these UIs (i.e., when a user interacts with them) and record information about whether the application has called one of these commands explicitly to enable the UI beforehand. If we don't collect this telemetry beforehand, we're effectively assuming that the breakage of this kind will be low enough that we are considering its risk low and acceptable. Okay, I'll change the default behavior only on Nightly before landing and I'll file a bug to collect telemetry data before landing the patches for the bug. > * Why are we *adding* a new command for enabling the absolute > positioning UI if we believe this UI is not useful and should be > disabled? Do we have any indication that web developers want to use > this UI in some cases, and for Firefox only? Have we heard any plans > from other browser vendors that they're interested to add support for > similar UI in the future? The Github issue you linked to makes that > sound unlikely. Wouldn't it be better to just disable the absolute > positioning UI? I think that Gecko specific feature may cause unexpected result for web apps and could cause unexpected error on some web apps, then, at worst, Firefox is banned by UA sniffing. Hmm, if the risk of removing this UI is so high, then shouldn't we collect some telemetry data that shows that removing it is safe before attempting to do so? I worry about some specific cases such as using Firefox as default browser in organization and depending on such feature. I don't worry about public web apps since if those features are necessary, they need to implement those features by themselves anyway since the other browsers don't have the features. (FWIW I don't understand how this UI showing and not showing can break an editing app so badly that web developers start to ban Firefox UAs. One way I can imagine is if they attempt to provide their own similar UI and ours overrides it, but since we are talking about changing things to hide the UI that we used to show, I don't think that's the risk you have in mind.) I worry about the case, if web app vendors don't want to allow users to modifying sizes, positions, etc, it means that only Firefox users may change them if they didn't disable the UI with the Gecko specific commands. If related applications of such web apps do not assume such points are changeable, they may receive complains only from Firefox users. It must be annoying thing for their business manager since the market share isn't high. Making it's disabled by default but making it possible to enable with execCommand, we can collect actual usage with telemetry as I said above. I think we can collect some telemetry data today. For example, we can collect data on how many HTML editor instantiations see the absolute positioning UI, and also how many of the times we display this UI the user ends up interacting with it. The problem with adding a new command and try to collect telemetry after that is that you're expecting Web developers to first update their code to use the new command before any meaningful telemetry data can be gathered, and then our hope would be that the data would suggest that the feature is unused so that we can tell the few Web
Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default
On 4/6/2018 2:50 AM, Ehsan Akhgari wrote: Hi Masayuki, First of all, thank you for taking on this task. I have a few questions. * What does the backwards compatibility story for these changes look like? Would we end up for example throwing exceptions or returning a different value from execCommand/queryCommandState/etc for one of the existing two commands? If there are any backwards compatibility concerns, what are your plans for them? Note that these two commands are extremely popular in existing code that knows about Gecko (since it typically has to start off by disabling this UI as you've noted.) It *might* be possible that a few web apps (including intranet only apps) may allow users to resize some elements, edit table structure and/or move absolute positioned elements with these built-in UI only on Firefox. If such apps actually exist, they can enable the Gecko specific UI explicitly with using execCommand. Then, we can collect actual usage with telemetry. * Why are we *adding* a new command for enabling the absolute positioning UI if we believe this UI is not useful and should be disabled? Do we have any indication that web developers want to use this UI in some cases, and for Firefox only? Have we heard any plans from other browser vendors that they're interested to add support for similar UI in the future? The Github issue you linked to makes that sound unlikely. Wouldn't it be better to just disable the absolute positioning UI? I think that Gecko specific feature may cause unexpected result for web apps and could cause unexpected error on some web apps, then, at worst, Firefox is banned by UA sniffing. Making it's disabled by default but making it possible to enable with execCommand, we can collect actual usage with telemetry as I said above. * What is our long term plan for this UI, do we want to keep them around or is this us deprecating the UI with the ultimate intention of measuring their usage so that we can eventually remove them? I think removing this UI is at least desirable from the implementation standpoint. The way that the native anonymous content this UI uses is hooked up (in https://searchfox.org/mozilla-central/rev/f860c2bf00576959b07e2d9619c7b5088b0005be/editor/libeditor/HTMLAnonymousNodeEditor.cpp#143) is different than everything else inside Gecko and has historically been a source of bugs, and we've never invested any effort to improve it since we believed the UI wasn't really worth the investment... I think that we'll get evidence which indicate nobody uses those Gecko specific feature, we can move those UI into comm-central or just remove them completely. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Are there some lists of web sites which use vertical writing-mode?
Hi, I'm currently reviewing bug 1358017 which tries to scroll vertical writing mode contents horizontally with vertical mouse wheel operation for some mice which have only vertical wheel and etc. https://bugzilla.mozilla.org/show_bug.cgi?id=1358017 I'd like to check actual behavior with actual devices on web sites which use vertical writing-mode in real world before making it enabled in release channel. Does somebody know some lists of web sites which use vertical writing-mode? Unfortunately, I don't know web sites which use writing-mode heavily even though I usually read web sites written in Japanese... -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to disable (hide) Gecko specific editing UI of HTML editor by default
On 4/6/2018 9:25 AM, Makoto Kato wrote: > * Add new command "enableAbsolutePositionEditing" command for allowing to enable #4 There is no way to use absolute position editing on Firefox because cmd_abspos is used by comm-central only. So I guess that it might be unnecessary to add this command for Firefox and is better to add a preference to enable it as default. No, try this: 1. Go to https://d-toybox.com/studio/lib/input_event_viewer.html 2. Input "div" into the first next to . 3. Select the radio button labelled . 4. Click black border box under the toolbars. Then, you'll see grabber to move the black border box at top edge of the box and you can move the box with dragging. That's one of the feature of absolutely positioned editor available even on Firefox. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are there some lists of web sites which use vertical writing-mode?
On 4/10/2018 4:40 PM, Brian Birtles wrote: On Fri, Apr 6, 2018 at 10:26 AM, Masayuki Nakano <masay...@d-toybox.com> wrote: Does somebody know some lists of web sites which use vertical writing-mode? Unfortunately, I don't know web sites which use writing-mode heavily even though I usually read web sites written in Japanese... For Japanese there is a list of showcase sites at: http://tategaki.github.io/ Thank you Brian! But interestingly and surprisingly, most web pages in the list use specifying only a some paragraphs. I.e., main block flow direction is top to bottom. Only hatenablog's template causes horizontal scrollable elements like <http://oriha-katten.hatenablog.jp/>. This is what I'm interested in currently. Really interesting... -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to disable (hide) Gecko specific editing UI of HTML editor by default
This incompatibility is pointed by W3C's Editing API WG:
https://github.com/w3c/editing/issues/171
Gecko has some specific editing UI of HTML editor.
1. Resiziers of , , absolute positioned elements.
2. Adding new table row/column from buttons.
3. Removing existing table row/column from buttons.
4. Grabber to move absolute positioned element.
Currently, all of those UIs are not implemented by the other browsers.
However, they are available in Gecko by default.
Therefore, web app developers need to disable those features with:
document.execCommand("enableObjectResizing",
false, false); // #1
document.execCommand("enableInlineTableEditing",
false, false); // #2 and #3
So, if web apps don't call them, only Firefox users can modify or
elements as unexpected for their developers.
Additionally, web apps cannot disable only #4.
So, for solving this incompatibility issue, we should:
* Disable those UI by default
* But allow to enable those UI for backward compatibility
* Add new command "enableAbsolutePositionEditing" command for allowing
to enable #4
I'm working on this incompatibility issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449564
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Are there some lists of web sites which use vertical writing-mode?
On 4/10/2018 5:53 PM, Karl Dubost wrote: Masayuki, Le 6 avr. 2018 à 17:26, Masayuki Nakano <masay...@d-toybox.com> a écrit : Does somebody know some lists of web sites which use vertical writing-mode? Kobo Taiwan for example has preview of books in vertical writing mode. see https://webcompat.com/issues/14152 Thank you. However, oddly, I cannot show the preview on Firefox nor Nightly. When I click the "preview", the website says "saved the preview" but I cannot access the preview actually. It might be not available from Japan. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are there some lists of web sites which use vertical writing-mode?
On 4/10/2018 5:27 PM, Brian Birtles wrote: On Tue, Apr 10, 2018 at 10:19 AM, <z...@zjz.name> wrote: Thanks for sharing. But it's not exactly what is being looked for. We are looking for websites in an overall vertical writing mode, not ones mixed with vertical writing text. That is, there should be a horizontal scrollbar in the page, and the scrollbar controls the page's *major* scrolling direction. Did you see this example at the bottom of the page? e.g. http://info.nicovideo.jp/indies-game-fest/history/ It doesn't have a horizontal scrollbar but it does scroll horizontally. This is interesting case. This is not what we're looking for, but this is a case of web developers trying to fix the issue by themselves. I.e., they must be thinking that horizontal scroll isn't useful even if the block direction is completely horizontal. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are there some lists of web sites which use vertical writing-mode?
On 4/11/2018 4:34 PM, Karl Dubost wrote: Le 11 avr. 2018 à 15:14, Masayuki Nakano <masay...@d-toybox.com> a écrit : However, oddly, I cannot show the preview on Firefox nor Nightly. When I click the "preview", the website says "saved the preview" but I cannot access the preview actually. It might be not available from Japan. You need to register an account on kobo to see the preview. Note that the thing is pretty badly implemented in both Chrome and Firefox. Yeah, I created an account, but I couldn't access the preview UI. Where did you click or something to show preview? -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: nsIEditor.numberOfUntoItems and nsIEditor.numberOfRedoItems
A patch to remove nsIEditor.numberOfUntoItems and nsIEditor.numberOfRedoItems are now landed: https://bugzilla.mozilla.org/show_bug.cgi?id=1448780 As far as I've investigated, nobody (including comm-central and bluegriffon) uses these XPCOM methods since those methods exactly equal to nsIEditor.transactionManager.numberOfUntoItems and nsIEditor.transactionManager.numberOfRedoItems. So, we don't need to keep maintaining these shortcut methods anymore. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: nsIClipboardDragDropHooks and nsIClipboardDragDropHookList interfaces
I'd like to remove nsIClipboardDragDropHooks and nsIClipboardDragDropHookList interfaces: https://bugzilla.mozilla.org/show_bug.cgi?id=1448876 These interfaces provide ability to override drag and drop operation and paste operation on editor. However, currently, this feature isn't used by anybody (it seems that it was used by ChatZilla, but according to its website, it's not active) and this causes a lot of unnecessary virtual calls and QI at D and Paste in editor. So, I don't think that we should keep this feature anymore. -- Masayuki Nakano <masay...@d-toybox.com> Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: Start to dispatch "keydown" and "keyup" events even if composing (only in Nightly and early Beta)
I'd like to start to dispatch "keydown" and "keyup" events even if
composing, i.e., there is composition string of IME but only on Nightly
and early Beta for now.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446401
This follows other browsers' behavior and conforms to UI Events spec:
https://w3c.github.io/uievents/#event-type-keydown
https://w3c.github.io/uievents/#event-type-keyup
https://w3c.github.io/uievents/#events-composition-key-events
Before this change, I changed EventUtils.synthesizeComposition() and
EventUtils.synthesizeCompositionChange() to dispatch keydown event and
keyup event if you don't specify |key: {}| or |key: null| explicitly.
https://bugzilla.mozilla.org/show_bug.cgi?id=1446253
So, if you write mochitests to test composition events, this new
behavior is tested automatically (e.g., whether the composition is
accidentally committed by a keydown or keyup event handler).
Some additional info:
Gecko's traditional behavior of keyboard/composition/input events are:
1-1: keydown
1-2: compositionstart
1-3: compositionupdate
1-4: input
1-5: compositionupdate
1-6: input
1-7: compositionupdate
1-8: input
1-9: compositionend
1-10: input
1-11: keyup
This becomes:
2-1: keydown
2-2: compositionstart
2-3: compositionupdate
2-4: input
2-5: keyup
2-6: keydown
2-7: compositionupdate
2-8: input
2-9: keyup
2-10: keydown
2-11: compositionupdate
2-12: input
2-13: compositionend
2-14: input
2-15: keyup
If you want to do nothing during composition with keydown/keyup
listeners, you can do it really easily:
foo.addEventListener("keydown", (e) => {
if (e.isComposing) {
return;
}
// Do anything what you want to do.
});
KeyboardEvent.isComposing is set to true if "keydown" and "keyup" events
are fired between "compositionstart" and "compositionend".
And be aware, if keydown and keyup events are already processed by IME,
their keyCode value is set to 229 (KeyboardEvent.DOM_VK_PROCESSKEY) and
their key value is set to "Process". I call those keyboard events as
"marked as processed by IME". So, you cannot retrieve actual key
information with KeyboardEvent.keyCode nor KeyboardEvent.key. However, I
cannot say which "keydown" and "keyup" events in above example are
marked as "processed by IME" because it depends on native IME's behavior
and OS itself. Typically keydown events (including the one immediately
before compositionstart) are marked as "processed by IME", but keyup
events are not marked as "processed by IME". So, except the "keydown"
event immediately before "compositionstart", using
KeyboardEvent.isComposing is really safer.
Finally, please do NOT use "keydown" events and "keyup" events for doing
something what should be done immediately after every character input.
In such purpose, "input" event is the right event because "keydown"
event and "keyup" event may not be fired even after the bug fix. For
example, if the IME is backend of voice input or handwriting system,
Gecko won't fire "keydown" nor "keyup" event unless OS or IME
synthesizes native key events for backward compatibility. And if native
IME completely consumes native key events before Gecko, Gecko won't fire
those events too.
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to stop dispatching "keypress" event for non-printable keys and key combinations in Nightly and early Beta
I'd like to stop dispatching "keypress" event for non-printable keys and
key combinations in the default event group of web content in Nightly
and early Beta for collecting regression reports.
https://bugzilla.mozilla.org/show_bug.cgi?id=1440189
By UI Events, "keypress" event is defined as:
> this event MUST be dispatched when a key is pressed down,
> if and only if that key normally produces a character value.
https://w3c.github.io/uievents/#event-type-keypress
So, non-printable key means:
* Function keys like ArrowLeft, ArrowDown, F1, Home, End, Tab, etc.
* Ctrl + KeyA etc.
Note that Enter key is special. Other browsers' behavior of "keypress"
event for Enter key is not same. However, unmodified Enter,
Shift+Enter, Ctrl+Enter causes any browsers and any platforms.
Therefore, we'll continue to dispatch "keypress" event only for those
key combinations.
https://github.com/w3c/uievents/issues/183
If you're a developer of our UI, please consider to use "keydown" event
listener to handle non-printable keys and key combinations. However,
calling preventDefault() of "keydown" event stops dispatching the
following "keypress" event. Therefore, if you cannot handle even
non-printable keys with "keydown" event since other "keypress" event
listeners in our UI are broken by calling preventDefault(), you can keep
using "keypress" event listeners in the system event group or in chrome
document.
You can add an event listener in the system event group with using
nsIEventListenerService::addSystemEventListener():
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEventListenerService#addSystemEventListener()
Or, specify group="system" to event handler in XBL like this:
https://searchfox.org/mozilla-central/rev/14d933246211b02f5be21d2e730a57cf087c6606/toolkit/content/widgets/browser.xml#1680
Or, you might be able to use EventTarget.addEventListener() with
{mozSystemGroup: true} as 3rd argument. However, I couldn't fix new
oranges with this approach. So, it works with some condition, but I
don't know about this.
So, I'll keep struggling with regressions of this behavior change.
However, probably, we won't get regression reports for minor UI, e.g.,
running only first time to use something. So, I'd be happy everyone to
check your own UI.
Thanks in advance.
--
Masayuki Nakano <masay...@d-toybox.com>
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Intent to (re-)enable new keyCode/charCode values of keypress events in Nightly
This is blocker issue of enabling window.event [*1].
When we enable window.event, a lot of web sites are broken like this code:
> foo.addEventListener("keypress", function (event) {
> var charCode;
> if (window.event) {
> charCode = event.keyCode;
> } else {
> charCode = event.which;
> }
> // do something with |charCode|...
> });
window.event was introduced by Internet Explorer, and IE sets charCode
value to keyCode and which. Chrome follows this behavior.
On the other hand, Gecko has kept taking traditional style of ours. That
is, when pressing key causes inputting a character, sets charCode and
which to the Unicode code point of the character, and sets keyCode to 0.
Otherwise, i.e., does not cause inputting a character, sets keyCode and
which to keyCode value of the key, and sets charCode to 0.
So, enabling window.event causes we start to use path for IE even though
our keyCode/charCode values of keypress events are different from IE's.
Therefore, we started to use the IE style in Nightly at bug 1479964
[*2]. (I'm really sorry, I forgot to email to dev-platform at this time.)
However, that causes breaking Google Closure and web apps which use
Google Closure. Therefore, I disabled it with turning off the pref [*3].
Now, the new behavior will be re-enabled in Nightly by default again,
but with blacklist (currently, Google Docs and Remember The Milk are in
it) [*4].
If you find new regression about key operation in some web apps, please
file a bug for each web app, and block bug 1479964.
1: https://bugzilla.mozilla.org/show_bug.cgi?id=218415
2: https://bugzilla.mozilla.org/show_bug.cgi?id=1479964
3: https://bugzilla.mozilla.org/show_bug.cgi?id=1497546
4: https://bugzilla.mozilla.org/show_bug.cgi?id=1502795
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value
We've decided to put this off at least 66. https://bugzilla.mozilla.org/show_bug.cgi?id=1520756 On 2018/11/30 10:37, Masayuki Nakano wrote: Summary: We'll set keyCode of "keypress" event to its charCode value if keyCode is 0, charCode of "keypress" event to its keyCode value if charCode is 0. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1479964 Link to standard: "conflated model" of https://w3c.github.io/uievents/#determine-keypress-keyCode (we've used "split model"). But no declaration of charCode value of Enter key press. (Oh, I had not realized this section when I wrote the commit message...) Platform coverage: All Estimated or target release: 65 DevTools bug: N/A Do other browser engines implement this? Yes, the other browsers use this behavior traditionally, and UI Events declared this behavior as "conflated model". web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. This new behavior was enabled in Nightly since early of 65. This caused breaking Google Closure Library. However, it have been fixed by the cooperation of the developers. Of course, we may meet other broken web apps especially in intranet. While we're testing this behavior in Nightly, we used blacklist pref (dom.keyboardevent.keypress.hack.use_legacy_keycode_and_charcode) to disable this new behavior only in specific domains. If we'll get broken web apps even after release, we and users can disable it with using this blacklist. Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to put off to ship: Event.returnValue
Event.returnValue is legacy attribute which was introduced by IE. We released this feature at 63, but it broke an internet application (bug 1478102). Therefore, we unshipped it temporarily at 64 because the fix of bug 1479964 will fix the intranet application. However, unfortunately, the fix broke another internet app (bug 1514940). Therefore, we put off to reship this at least until 66. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: window.event
We've decided to put this off at least 66. https://bugzilla.mozilla.org/show_bug.cgi?id=1520756 On 2018/11/30 10:47, Masayuki Nakano wrote: Summary: Enable window.event which can access dispatching event from everywhere. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=218415 Link to standard: https://dom.spec.whatwg.org/#ref-for-dom-window-event Platform coverage: All Estimated or target release: 65 DevTools bug: (not sure) Do other browser engines implement this? (I think so, but I'm not sure because of not my fix.) Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. This was disabled temporarily due to a lot of web apps assume that window.event is available only in IE, and IE stores a Unicode code point in keyCode of "keypress" event. Google Chrome and Edge followed same behavior for both, so, such apps work even with them. This is now fixed by the both fixes of: https://groups.google.com/forum/#!topic/mozilla.dev.platform/E8DyIJBhu1g https://groups.google.com/forum/#!topic/mozilla.dev.platform/IWLLJmoGroA -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: InputEvent.inputType (with Input Events Level 1)
Summary: Implement and ship InputEvent.inputType for conforming to Input Events Level 1. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1447239 Link to standard: InputEvent.inputType: https://w3c.github.io/uievents/#dom-inputevent-inputtype Value of InputEvent.inputType: Level 1: https://rawgit.com/w3c/input-events/v1/index.html#interface-InputEvent-Attributes Level 2: https://w3c.github.io/input-events/#interface-InputEvent-Attributes Platform coverage: All Estimated or target release: 66 DevTools bug: N/A Do other browser engines implement this? Safari supports Level 2, Chrome supports Level 1, Edge does not support this. web-platform-tests: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/input-events # And I add a lot of inputType check into existing mochitests. This attribute is set to the reason why the "input" event is fired. This is not so important for "input" event but really important for "beforeinput" event which should be implemented as soon as possible. The value list difference between Level 2 and Level 1 is, Level 2 adds some inputType value for IME composition. However, Chrome team decided that they ship it with Level 1 due to risk management. And I see some spec issues of Level 2, so, I think that Level 2 is still unstable spec. So,from points of view of both compatibility and risk management, we should use Level 1 values for now (but you can switch to Level 2 support with pref, "dom_input_events.conform_to_level_1", although could be changed in review process). -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input
Summary: We'll stop dispatching non-printable "keypress" events. "non-printable" means that key press or key combination does not introduce text input without IME. For example, arrow key press, Ctrl+A, etc. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=968056 Link to standard: For keys which introduce text input: https://w3c.github.io/uievents/#legacy-keyboardevent-event-types For Enter key: https://github.com/w3c/uievents/issues/183 Platform coverage: All Estimated or target release: 65 DevTools bug: N/A Do other browser engines implement this? Yes, the other browsers use this behavior traditionally, and UI Events declared the behavior as "standard". web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. This new behavior was enabled in Nightly since 61. This caused breaking a lot of major web apps. However, all of them have been fixed by the cooperation of the vendors. Of course, we may meet other broken web apps especially in intranet. While we're testing this behavior in Nightly, we used blacklist pref (dom.keyboardevent.keypress.hack.dispatch_non_printable_keys) to disable this new behavior only in specific domains. If we'll get broken web apps even after release, we and users can disable it with using this blacklist. Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: dispatching "keydown" and "keyup" events during IME composition
Summary: We'll start to dispatch "keydown" and "keyup" events during IME composition. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=354358 Link to standard: https://w3c.github.io/uievents/#events-composition-key-events Platform coverage: All Estimated or target release: 65 DevTools bug: N/A Do other browser engines implement this? Yes, the other browsers use this behavior traditionally, and UI Events declared the behavior as "standard". web-platform-tests: N/A due to requiring user input with IME, but we have mochitests with synthesized events. This new behavior was enabled in Nightly and Early-Beta since 61. This behavior is mainly expected by Korean web developers but we've not implemented this for a long time. For reducing the testing and developing cost of each web app vendor, we've waited to ship keypress event changes which will be mentioned in following posts. Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value
Summary: We'll set keyCode of "keypress" event to its charCode value if keyCode is 0, charCode of "keypress" event to its keyCode value if charCode is 0. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1479964 Link to standard: "conflated model" of https://w3c.github.io/uievents/#determine-keypress-keyCode (we've used "split model"). But no declaration of charCode value of Enter key press. (Oh, I had not realized this section when I wrote the commit message...) Platform coverage: All Estimated or target release: 65 DevTools bug: N/A Do other browser engines implement this? Yes, the other browsers use this behavior traditionally, and UI Events declared this behavior as "conflated model". web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. This new behavior was enabled in Nightly since early of 65. This caused breaking Google Closure Library. However, it have been fixed by the cooperation of the developers. Of course, we may meet other broken web apps especially in intranet. While we're testing this behavior in Nightly, we used blacklist pref (dom.keyboardevent.keypress.hack.use_legacy_keycode_and_charcode) to disable this new behavior only in specific domains. If we'll get broken web apps even after release, we and users can disable it with using this blacklist. Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship: window.event
Summary: Enable window.event which can access dispatching event from everywhere. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=218415 Link to standard: https://dom.spec.whatwg.org/#ref-for-dom-window-event Platform coverage: All Estimated or target release: 65 DevTools bug: (not sure) Do other browser engines implement this? (I think so, but I'm not sure because of not my fix.) Enabling patch has been landed from: https://bugzilla.mozilla.org/show_bug.cgi?id=1496288 because we need to manage those changes as a set. This was disabled temporarily due to a lot of web apps assume that window.event is available only in IE, and IE stores a Unicode code point in keyCode of "keypress" event. Google Chrome and Edge followed same behavior for both, so, such apps work even with them. This is now fixed by the both fixes of: https://groups.google.com/forum/#!topic/mozilla.dev.platform/E8DyIJBhu1g https://groups.google.com/forum/#!topic/mozilla.dev.platform/IWLLJmoGroA -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: stop dispatching "keypress" events when pressed key (key combination) does not introduce text input
On 2018/12/01 8:51, Eli Grey via dev-platform wrote: I think the spec is confusing and not well-reasoned enough to introduce this misnomer. This change will make it so that there are two events with synonymous meaning, and only introduces potential site breakage. The event is literally called "keypress", not "input". Developers are going to end up using it to track keypresses regardlessly due to the incorrect name. If they want to track input, that's what the "input" event is for. "keypress" event was introduced by IE, and UI Events (formerly, called DOM Level 3 Events) defines the behavior from existing browsers, but marking them as "legacy". Under current spec, "keydown" and "keyup" events represent "physical" event on the input device. "keypress" is "logical" event of text input from keyboard directly (i.e., not via IME). "input" and "beforeinput" are similar to "keypress", but they are fired only when an editor has focus and with any input devices/middle wares. Currently, I'm working on implementing "beforeinput". It allows all web apps to stop handling "keypress" in the future and to prevent default action easier. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: set keyCode or charCode of "keypress" event to the other's non-zero value
On 2018/11/30 20:42, James Graham wrote: On 30/11/2018 01:37, Masayuki Nakano wrote: web-platform-tests: N/A due to requiring user input, but we have mochitests with synthesized events. I think it should be possible to write web-platform-tests for this kind of thing now, using the testdriver API and in particular the actions support see e.g. [1], [2] If this still doesn't meet your use case please let me know because we should work out how to make testing this kind of stuff possible cross-browser; as you well know UI events have been an interop nightmare in the past and we can't afford to let that situation continue into the future for new devices and APIs. [1] https://web-platform-tests.org/writing-tests/testdriver.html [2] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/infrastructure/testdriver/actions/multiDevice.html Thank you for the information. I'm looking for the implementation of the keyboard event dispatchers, but I've not found it yet. Could you let me know where it is? FYI: Generally, for testing Gecko itself, test API should fill all attributes of KeyboardEvent with usual value for the key unless testing special cases. Additionally, dispatched event should be trusted event and has widget internally, and propagated the DOM tree as actual user input events. It seems that synthesized events won't be initialized with our widget nor tables in JS like synthesizeKey() in EventUtils.js. For example, keyCode value of punctuation keys are different between browsers/platforms/environments. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to unship: DOM "text" event
Summary: We'll stop dispatching DOM "text" event which is Mozilla specific DOM event and really not useful. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1288640 Link to standard: N/A It's mentioned by MDN only here: https://developer.mozilla.org/en-US/docs/Mozilla/IME_handling_guide#eCompositionChange DevTools bug: N/A Do other browser engines implement this? No. web-platform-tests: N/A This was implemented to notify our editor of composition string data and IME selection ranges with DOM event and the information is available only from C++ event listeners. So, this should not have been exposed to the web since first implementation. Additionally, we might need to change "compositionupdate" event dispatcher if Input Events Level 2 spec would keep current definition. Therefore, if we stop using DOM event to handle IME composition in our editor, we can make maintain around it easier. Currently, we should stop dispatching "text" events only in the default group of web content. I.e., we should hide the event only from web apps. If this won't cause any problem with the web, we should get rid of the event completely later. Note that this event is listened by only 0.0003% inner-windows for now (currently, we collect the data only from Nightly testers). -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Stop including nsIPresShell.h, include mozilla/PresShell.h instead
Hi, I'm trying to get rid of nsIPresShell. nsIPresShell.h is anyway included by mozilla/PresShell.h. So, even if you use only nsIPresShell newly, please include mozilla/PresShell.h instead. FYI: Currently, Document::GetPresShell(), nsPresContext::GetPresShell(), nsPresContext::PresShell(), nsFrameSelection::GetPresShell(), Selection::GetPresShell(), KeyframeEffect::GetPresShell(), EditorBase::GetPresShell() and EditorEventListener::GetPresShell() return mozilla::PresShell* rather than nsIPresShell*. So, when you use them, you can now use PresShell* or RefPtr for storing the result. I'll keep changing other GetPresShell() methods too when I have time, but of course, you're welcome if you do that instead of me ;-) Regards, -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Each piece of PresShell::HandleEvent() and PresShell::HandleEventInternal() was spun out to each method of PresShell::EventHandler class
Hi, We had too big, complicated and important method, `PresShell::HandleEvent()` (*1), and its helper method, `PresShell::HandleEventInternal()` (*2). Those methods were too risky to fix everything. Therefore, I redesigned them with a stack class `PresShell::EventHandler` (*3). This new class is created in the stack temporarily when `PresShell::HandleEvent()` or similar methods are called, or handling event is retargeted to different `PresShell`. Note that I did not fix found bugs except trivial ones. So, if you need to check the blame, it must be easier to do it starting from the first link below since it may not be easy to check moved lines. 1. https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#6464-7122 2. https://searchfox.org/mozilla-central/rev/9b614455de573ad1cac56fd1dbac73adde3425bc/layout/base/PresShell.cpp#7190-7586 3. https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/layout/base/PresShell.h#499-1261 -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Moving reviews to Phabricator
Thank you very much, really helpful information. On 2019/02/08 4:43, Kartikaya Gupta wrote: Ditto for git. Also note that when you click the "preview landing" button in Lando, the popup that shows the commits shows the author information on the patch, so you can use that to verify that the attribution is correct. On Wed, Feb 6, 2019 at 8:10 PM Barret Rennie wrote: If you commit with `hg commit -u` and post it to Phabricator, it will show up as authored by you in Phabricator, but when it lands it will have the correct attribution (i.e., the user you specified with `-u`). - brennie On Wed, Feb 6, 2019 at 7:27 PM Masayuki Nakano wrote: I sometimes rewrite patches from new contributor and commit them with `-u` and the contributors name and email address, and land the patches for them. E.g., https://bugzil.la/1513405 Is it possible to do that via Phabricator and Lando? If not, what should I do when I meet similar situation? Of course, it is the best that contributors work all for their patches, but in my experience, they may not update their patches after review or they may don't have much time to update quickly. So, I think that full timers should support them as far as possible. On 2019/02/07 5:42, Kim Moir wrote: On February 28 Bugzilla review flags will be disabled for Firefox and other mozilla-central products and components. From this point forward, all reviews of code changes to mozilla-central should be conducted in Phabricator. Tasks that have been identified as crucial to this transition have been set as blocker bugs to https://bugzil.la/1514775. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: InputEvent.data and InputEvent.dataTransfer
We need to implement InputEvent.data and InputEvent.dataTransfer because
they are important information for web apps especially for "beforeinput"
event listeners. So, we need to implement these attributes before
implementing "beforeinput" event. The bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=998941
Those attributes tell what content is inserted ("input") or will be
inserted ("beforeinput") to web apps.
The former is declared by UI Events:
https://w3c.github.io/uievents/#dom-inputevent-data
The latter is declared by Input Events:
https://rawgit.com/w3c/input-events/v1/index.html#dom-inputevent-datatransfer
https://w3c.github.io/input-events/#dom-inputevent-datatransfer
And their values are defined by Input Events:
https://rawgit.com/w3c/input-events/v1/index.html#overview
https://w3c.github.io/input-events/#overview
Those are implemented by both Chrome and Safari, but their
implementation are not enough though (e.g., "input" event is not set
those values properly in a lot of cases). But I'm going to add check of
those attributes into WPT as far as possible at landing the patches and
I'll file bugs for them.
Currently, I plan to enable them by default in all channels like
InputEvent.inputType. If we would get web-compat issues, e.g., they are
used to detect "beforeinput" event support, then, I'd disable them in a
follow up bug.
--
Masayuki Nakano
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Moving reviews to Phabricator
I sometimes rewrite patches from new contributor and commit them with `-u` and the contributors name and email address, and land the patches for them. E.g., https://bugzil.la/1513405 Is it possible to do that via Phabricator and Lando? If not, what should I do when I meet similar situation? Of course, it is the best that contributors work all for their patches, but in my experience, they may not update their patches after review or they may don't have much time to update quickly. So, I think that full timers should support them as far as possible. On 2019/02/07 5:42, Kim Moir wrote: On February 28 Bugzilla review flags will be disabled for Firefox and other mozilla-central products and components. From this point forward, all reviews of code changes to mozilla-central should be conducted in Phabricator. Tasks that have been identified as crucial to this transition have been set as blocker bugs to https://bugzil.la/1514775. -- Masayuki Nakano Software Engineer, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Patching FF 52.9esr with v60+ Security updates possible?
I think it's not easy to do that for some modules. E.g., starting from Firefox 57, we removed a lot of XPCOM interfaces/objects. That caused redesigning some implementation around them (for making simpler and faster). Additionally, some refactoring must have been done in the period. For example, my owning module `editor` has been rewritten at almost all lines in the period. So, porting patches for such places require to understand each patch what it does. On 2019/04/13 7:43, Charles Robertson wrote: Hi, I know this sounds like a strange questions. However, we have a very large customer who is using our old OS which the last successful build of Firefox ESR was 52.9. But because of the massive updates to FF 60 we have been unable to get FF 60+ to build on that old OS. This customer has demanded we provide an updated Firefox for this old OS so I am asking if it would be possible to patch FF 52.9esr with the security updates since 60 was released? Thanks, Cheers Charles Robertson Firefox Maintainer - SUSE ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Masayuki Nakano Working on DOM, Events, editor and IME handling at Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: AbstractRange and StaticRange
Summary: Implement StaticRange and makes it and Range inherits AbstractRange Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1444847 Link to Standards: https://dom.spec.whatwg.org/#abstractrange https://dom.spec.whatwg.org/#staticrange Platform coverage: all Estimated or target release: 69 (or later if we'd meet web-comoat issue) Preference behind which this will be implemented: none Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: N/A Do other browser engines implement this? a little bit complicated, see below. web-platform-tests: Only interface existence is tested. Is this feature restricted to secure contexts? No StaticRange is simpler range than Range (nsRange internally). Different from Range, StaticRange does not modify its start boundary nor end boundary when the DOM tree is modified. In other words, StaticRange keeps storing start and end boundaries when it's created. This is currently implemented by Chrome, Safari and Edge. This was declared with constructor but current it's explicitly removed. AbstractRange is common interface of Range and StaticRange. This also does not have constructor. Chrome supports this interface. Both of them cannot be created from WebAPI for now. StaticRange will be used as result of InputEvent.getTargetRanges(). https://w3c.github.io/input-events/#dom-inputevent-gettargetranges So, we just exposes the interfaces for now, but I think that nobody uses this for feature detection. -- Masayuki Nakano Working on DOM, Events, editor and IME handling at Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
nsIPresShell has gone
Hi, everybody. Finally, I completely got rid of nsIPresShell from our tree. https://bugzilla.mozilla.org/show_bug.cgi?id=253889 If you need to access presentation shell, treat mozilla::PresShell directly (note that in some classes like nsIFrame and its subclasses, `mozilla::` prefix is necessary due to the class has a method `PresShell()`). If you need to public `enum` or `struct` of `nsIPresShell`, they have been moved to `mozilla` namespace in `PresShellForwards.h`. https://searchfox.org/mozilla-central/source/layout/base/PresShellForwards.h I guess that this fix does not devirtualize the methods of them newly, they perhaps have already been done by compiler. -- Masayuki Nakano Working on DOM, Events, editor and IME handling at Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
