We didn't have any ideas of crossing mouse/pointer events which finally cause
synthesized move event to dispatch corresponding boundary events. However,
`mSynthesizeMoveAfterDispatch` of `eMouseUp` is set to `true` in most cases
because the preceding `ePointerUp` causes releasing implicit capture and
`eMouseUp` may be handled in `EventStateManager::HandleCrossProcessEvent` if
there is a remote target underneath the pointer after `ePointerUp` is handled.
Therefore, we should allow such `eMouseUp` events to cross the process
boundary, but we don't need to copy the members (See the comment in
`ParamTraits<mozilla::WidgetMouseEvent>` for the reason).
I have no idea how to write the xorigin test within WPT. Therefore, this patch
does not contain new test.
Differential Revision: https://phabricator.services.mozilla.com/D220773
When an element starts capturing a pointer, pointer/mouse boundary events are
dispatched by `EventStateManager::PreHandleEvent` [1]. However, when the
capturing element loses the capture, they are not dispatched.
When the pointer capture is implicitly released, the pointer may be over another
document. Therefore, this patch synthesizes an internal `ePointerMove` and
`eMouseMove` on the widget to make `PresShell::HandleEvent` redirects the event
to proper document under the pointer.
Unfortunately, I add 2 manual tests into WPT. The reason is, a drag operation
across document boundary with test driver does not work even if I specify the
pointer position within the parent document coordinates. This is same both on
Firefox and Chrome. Additionally, writing the new tests as a mochitest won't
work too. If I use synthesized mouse events, I see similar failure.
Additionally, when I use native events, it works, but unstable to run on CI.
1. https://searchfox.org/mozilla-central/rev/669fac9888b173c02baa4c036e980c0c204dfe02/dom/events/EventStateManager.cpp#1139-1140
Differential Revision: https://phabricator.services.mozilla.com/D218896
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
The goal of this event is for doing hit testing in content and emit an
accessibility event with the result for Android's explore by touch.
This event allows us to use APZ's ability to target the correct content
doc.
Differential Revision: https://phabricator.services.mozilla.com/D132840
The behavior for non-trusted events matches Safari (Chrome does return
deltaX in that case, which seems pretty bogus, because the sign of the
wheelDelta* is the opposite as the delta* props).
Differential Revision: https://phabricator.services.mozilla.com/D114052
The behavior for non-trusted events matches Safari (Chrome does return
deltaX in that case, which seems pretty bogus, because the sign of the
wheelDelta* is the opposite as the delta* props).
Differential Revision: https://phabricator.services.mozilla.com/D114052
The automated tests become orange only in macOS and 32bit Windows builds. It
fails when left mouse button down is synthesized in the autoscroller (a XUL
`<panel>` element). Although I'm not sure why that depends on the platform,
APZ cancels active autoscrolling before dispatching `mousedown` event.
Therefore, `AutoScrollParent` nor `AutoScrollChild` cannot block the following
click event.
Therefore, this patch adds new field into `APZEventResult` and set it to `true`
when APZ runs `autoscroll` but canceled by a mouse input. Then, `nsBaseWidget`
can prevent following click event of `eMouseDown` and `eMouseUp` events as
expected before dispatching them into the DOM tree. (FYI: Preventing click
event of either `eMouseDown` or `eMouseUp` can prevent the following `click`
event, etc.)
Differential Revision: https://phabricator.services.mozilla.com/D107325
We already have a pref for double tap to zoom with is already enabled by default so it's kind of awkward to add another pref.
Differential Revision: https://phabricator.services.mozilla.com/D107389
We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us.
mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send.
This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do.
Differential Revision: https://phabricator.services.mozilla.com/D86495
The original code made the mistake of thinking that [event magnification] was a multiplicative quantity (ie if the scale changed from a to b then [event magnification] would be b/a). But it is an additive quantity (so b-a). If we then apply this knowledge to how we calculate the value from the Windows code we get the new formula.
The macOS and non-macOS code could be merged because mCurrentSpan is always 100.0 on macOS, but I'm not going to do that just yet because the Windows specific code isn't mature yet, so I'm not sure if we will need to tweak it more and my goal with this change was to just get the signs right to fix the worst bug. The scale can be addressed later if needed.
Differential Revision: https://phabricator.services.mozilla.com/D78479
The BothFingersLifted() mechanism was a bit of a hack to handle the case that
with touch inputs, a user might be able to lift just one finger to transition
from a pinch to a pan or other kind of gesture. This isn't possible with
other kinds of pinch gestures, such as on trackpads or with mousewheels.
So instead of tracking that via special-case behaviour of mFocusPoint, or
adding an extra bool to the PinchGestureInput class, it seems cleaner to
separate the concerns by adding a new type of input event that explicitly
covers the "finger lifted" touch scenario. This patch implements this change,
and removes the BothFingersLifted() machinery.
Differential Revision: https://phabricator.services.mozilla.com/D74415
Masayuki Nakano