Update the composition when setting/removing spans, so that we update
the selection/cursor during a composition. However, we must limit any
updating to the current composition only (as indicated by the
keep-current-composition flag), because the Facebook comment box behaves
incorrectly if we repeatedly start and end new compositions.
Due to bug 1358958, simply inserting a line breaker with composition events doesn't work as expected in HTML editor. Therefore, we need to dispatch "fake" Enter keypress event even if it's not handling Enter key actually or shouldn't dispatch keypress event anymore.
The method tries to dispatch Enter keypress event. If it's handling Enter key press actually and can dispatch keypress event normally, it dispatches Enter keypress event as-is. Otherwise, it tries to dispatch "fake" Enter keypress. It doesn't have Control, Option and Command key state for emulating to insert a line breaker. Additionally, its code value is not set to "Enter" because the fake key event isn't a physical key event.
If it cannot dispatch Enter keypress event, it dispatches composition events to insert "\n" even though it won't work in HTML editor.
MozReview-Commit-ID: 7AsJLKS8Tgz
--HG--
extra : rebase_source : 03a8628fd35eff404792691de0d2600f11ef1614
When typing Enter key when active keyboard layout is Korean IME and it has composition string, the composition string is committed and then, "insertNewline:" command is sent. However, TextInputHandler::DoCommandBySelector() consumes the command because the key event has already modified the composition string.
This patch makes TextInputHandler::DoCommandBySelector() consume the command if it's not handling keydown or neither dispatched keydown event nor dispatched keypress event (if it does) is consumed. Therefore, insertNewline:sender of nsChildView will be called later, then, it causes inserting a line break with a set of composition events.
MozReview-Commit-ID: Afr1FKZbUtL
--HG--
extra : rebase_source : 0c43986907553750b63bed0c95b3d5aaa1b16bea
PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
--HG--
extra : rebase_source : 4b29b859aa5745fabe3db0fe68742328fc0af175
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
1. add binding functions for -moz-border-*-colors support.
In Gecko, we use double pointers to nsBorderColors to store -moz-border-*-colors.
The computed values of -moz-border-*-colors are set by couple member functions.
To pass the computed value from Servo to Gecko, we need support for these member
functions as well. So, I'm adding some binding functions in this patch. The
actual use of these bindings to pass/store the computed values is separated
in the following patch, which should be a pure Servo change. See servo PR:
https://github.com/servo/servo/pull/16586.
2. update test expectations for -moz-border-*-colors support.
Note that with the support of -moz-border-*-colors, 165 mochitests and 17 reftests
could be fixed.
MozReview-Commit-ID: KDbp8C6Aoqd
--HG--
extra : rebase_source : 7d9675d9ece091ea6957dcae7d28c39066e69035
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements.
widget/cocoa/nsDeviceContextSpecX.mm:246:26 [-Wcomma] possible misuse of comma operator here
widget/cocoa/nsDeviceContextSpecX.mm:247:32 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: GhZQgNemLAE
--HG--
extra : rebase_source : 0bcc8d425ba700eb6025ad92b2999c16e07a082b
extra : source : 753076ad649966f1a9fa0c0e8bd3213ece860d28
Our "chrome-document-loaded" observer may detect several different types
of widgets that can exist in the parent process, including the Android
nsWindow, PuppetWidget, etc. We should only set the global state to
ready when the first top-level nsWindow has loaded, and not just any
window.
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
On my machine, if I have my mouse cursor positioned flush against the right
edge of my screen (which is 1440x900@2x), locationInWindow has an x coordinate
of 1439.99609375. This value was rounded up to an integer screen coordinate of
2880, and for that coordinate we don't find a target APZC, and consequently
refuse to scroll.
MozReview-Commit-ID: CJic4g3Y6Ag
--HG--
extra : rebase_source : 6e2405e9370046b5359d3800c1d0f70c3059074e
