The problem is, only when requesting IME to commit or cancel composition is handled synchronously, TabParent does not send the dispatched eCompositionCommit(AsIs) event to the remote process. Therefore, TabParent (and ContentCacheInParent) never receives the message from the remote process.
This patch makes TabChild notifies TabParent of eCompositionCommitRequestHandled special event message after TabChild dispatches eCompositionCommit into the DOM tree. Then, ContentCacheInParent should decrease mPendingCompositionCount and mPendingEventsNeedingAck as usual composition event messages.
MozReview-Commit-ID: 7ec5HPiE687
--HG--
extra : rebase_source : a9366abf6f8feec2d6ac639fd37f5b5c6ddd9586
This patch adds a new non-DOM event type, "mousetouchdrag". The name is horrible, I
know. The "mouse" comes from the fact that it's a WidgetMouseEvent, and the
"touchdrag" comes from the fact that this event is fired at the start of a touch
gesture for drag-and-drop. Right now this event is only fired from the Windows
widget code, when we receive a touch-source doubleclick event from the OS. This
event is sent to us from the OS when it detects the sequence "touchstart, touchend,
touchstart" within certain time/distance constraints. Eventually we may detect
similar gestures for other platforms in the APZ GestureEventListener and dispatch
the "mousetouchdrag" event for those as well.
The only effect of this event is that it begins tracking a drag gesture in the
EventStateManager. Subsequent touchmove events can begin the actual drag-and-drop
operation by calling ::DoDragDrop. See the discussion in bug 1147335 for some
important caveats about DoDragDrop and how it only works with left-mouse-button
events (real or synthetic).
MozReview-Commit-ID: bGyOk6dRoJ
We moved 'transitioncancel' event to the CSS-Transition Level 1.
The definition of 'transitioncancel' is as follow:
https://drafts.csswg.org/css-transitions-1/#transitioncancle
MozReview-Commit-ID: 1rEH0KjBrlL
--HG--
extra : rebase_source : c1d6ba635dd23cafcd0352b35e6c6cc714bb3ac4
After click events with button 2 or 3 are fired, fire auxclick, a new
event intended to represent a non-primary mouse click. Because this
event, based on the design examples and blink's implementation, is
intended to be used with content listeners, always dispatch on content
listeners--not just those that force all events to be dispatched (i.e.
document/window). This diverges from the behavior of our click events
from non-primary buttons.
Eventually, we hope this will replace click events for non-primary
buttons. For now, leave those events for compatibility reasons.
Additionally, add handling of this new event, where necessary.
MozReview-Commit-ID: 8osozM4h6Ya
--HG--
extra : rebase_source : 558261dd0d0b9241efa84ca168c50455850af03a
Blink and webkit launch focusin after focus and focusout after blur. Despite
this contradiction with the spec, it is best to mirror this new way, as there
is little guidance or existing code to clarify implementation amiguities that
can arise from the spec.
If focus/blur is fired on a window or document, or the event triggers a change
of focus, do not fire the corresponding focusin/focusout. Otherwise, always
fire the corresponding event.
Additionally, add a mochitest and a w3c-platform-test.
MozReview-Commit-ID: AgQ8JBxKIqK
This transitionstart and transitionrun event is defined in
editor's draft of CSS Transition Level 2.
https://drafts.csswg.org/css-transitions-2/#transition-events
MozReview-Commit-ID: 6c0GqlaOOPZ
--HG--
extra : rebase_source : 9d16572634a388da25e16096f06087e808ec57ae
It will use on ContentCache. Also, SetRangeFromFlatTextOffset issue will hanle on another bug.
MozReview-Commit-ID: 9Yu8bLlcZS5
--HG--
extra : rebase_source : c8eba70bdedf303b0fa649c1a609fe6120983e65
extra : histedit_source : 4189807b57ede13c1546e95052fcc298c8581d06
If a plugin process posts native key events to the widget, it needs to check if the key combination is reserved by chrome because if it's reserved by chrome, the reserved shortcut key handler should be executed and the event shouldn't be handled by the focused plugin.
This patches add eKeyDownOnPlugin and eKeyUpOnPlugin. nsXBLWindowKeyHandler will listen to them and handle them as normal keydown and keypress or keyup event. Note that these events won't be fired on content in the default event group and won't be sent to the remote process.
MozReview-Commit-ID: H5OKPLtVdr6
--HG--
extra : rebase_source : c6852423e47c40e9953b72061262730f7cce35d7
Add ontoggle event handler, and dispatch toggle events to the details
element if the open attribute is added or changed. According to the
spec, if a new toggle event has been queued, previous toggle events
should be aborted.
MozReview-Commit-ID: EN6Jf5hVHHD
--HG--
extra : rebase_source : 35605e49950bb59a0eb6dca594c3ede465ff587d
kevin
Nicholas Nethercote
Masayuki Nakano
Ehsan Akhgari
Stone Shih
Makoto Kato
Mantaroh Yoshinaga
Kearwood (Kip) Gilbert
Tim Nguyen
Kartikaya Gupta
Daosheng Mu
Kevin Wern
Michelangelo De Simone
Marcos Caceres
Kirk Steuber
Ben Tian
Wes Kocher
kearwood
Xidorn Quan
Jimmy Wang
Carsten "Tomcat" Book
Neil Deakin
Ting-Yu Lin
Xidorn Quan
Daniel Holbert
Eugen Sawin
Boris Zbarsky
William Chen