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
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
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
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
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
