`eMouseRawUpdate` and `eTouchRawUpdate` are internal event messages to
dispatch `ePointerRawUpdate` and
`IsForbiddenDispatchingToNonElementContent()` is just a utility method
to help to compute the event target. So, callers may want to know the
`ePointerRawUpdate` event target with `eMouseRawUpdate` or
`eTouchRawUpdate` event message. Therefore, the method should not assert
it and instead, `EventDispatcher::Dispatch` should check it since it's
the only one dispatcher of `WidgetEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D302943
As a follow-up on D295112, this patch removes the inclusion of CSS(Animation|Transition)
headers from ContentEvents.h by forward-declaring those classes and moving the implementations
that require complete types into WidgetEventImpl.cpp. This also required the followings:
- moving AnimationEventDispatcher::Dispatch() out of the header, because it also needs the
full definitions of CSS(Animation|Transition).
- adding CSS(Animation|Transition) headers to Event.cpp, which needs the full definitions and
had obtained them by including ContentEvents.h before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D298064
If it has wrong value, it's difficult to understand that how an odd
case caused by that occurred. So, detecting that as far as possible
makes it easier to understand the root cause.
Differential Revision: https://phabricator.services.mozilla.com/D295205
This is mostly the result of running ./mach static-analysis check --fix
with the new linter activated, with the following caveats:
- use std::fill when it makes sense
- use appropriate names for the loop target variable
- fix constness
- use array default initialization instead of an explicit loop when it
makes sense
Differential Revision: https://phabricator.services.mozilla.com/D289172
The parent process should handle only the shortcut key and access key
when it receives a reply key event. Thus, the editor commands are not
required, but the copy cost may not be cheap. Therefore, we should stop
copying them and the parent process should check whether the reply event
has unexpected edit commands or not.
And also this makes `nsGUIEventIPC.h` sanitizes the `KeyNameIndex` and
`CodeNameIndex`.
Differential Revision: https://phabricator.services.mozilla.com/D286456
On Windows, we do not spoof touch-related inputs anymore, and we
pretend touch is always available.
There is no reason not to do the same on Linux, even though the code to
report the number of maxTouchPoints is not implemented there.
Differential Revision: https://phabricator.services.mozilla.com/D267266
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
This reverts commit 35055c39b0.
Revert "Bug 1991701 - Re-enable touch on Linux with RFP and remove RFPTarget::PointerId. r=tjr,layout-reviewers,emilio"
This reverts commit 00f1baf7d5.
On Windows, we do not spoof touch-related inputs anymore, and we
pretend touch is always available.
There is no reason not to do the same on Linux, even though the code to
report the number of maxTouchPoints is not implemented there.
Differential Revision: https://phabricator.services.mozilla.com/D267266
The nsIControllerCommandTable already assumes it's an
nsControllerCommandTable as it has infallible casts. Similarly,
nsIControllerCommand doesn't need to be scriptable.
This is in preparation to expose a global list of always-enabled
commands for the IPC code to use and avoid sending back and forth.
Differential Revision: https://phabricator.services.mozilla.com/D263807
Pointer Events should be handled per `pointerId`. However, currently,
we dispatch pointer boundary events at a layout change only for the
last pointer which updated the last mouse location because we dispatch
a synthesized `ePointerMove` as a preceding pointer event of a synthetic
`eMouseMove`.
This patch makes `PointerInfo` store the last pointer state for each
`pointerId`. Then, the synthesizer can dispatch synthetic
`ePointerMove` for any active `pointerId`s. Finally, `PresShell` can
stop handling a preceding `ePointerMove` for a synthetic `eMouseMove`.
Differential Revision: https://phabricator.services.mozilla.com/D252780
This patch tries to dispatch ePointerRawUpdate with
PresShell::EventHandler::DispatchPrecedingPointerEvent as same as usual
pointer events.
For using the path, this patch adds 2 internal events, eMouseRawUpdate
and eTouchRawUpdate which are never dispatched into the DOM because
PresShell::EventHandler::DispatchPrecedingPointerEvent will return false
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is PresShell::EnsurePrecedingPointerRawUpdate(). This dispatches the
internal event if and only if the coming event of PresShell::HandleEvent will
cause ePointerMove. The reason why PresShell::HandleEvent handles the
preceding raw-update event is, we should support ePointerRawUpdate events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a pointerrawupdate event may destroy the target <iframe>.
In such ase, the following pointermove may need to be dispatched on its parent
window or another <iframe> window. Therefore, we need to dispatch the
internal raw update event before considering the target window (PresShell) and
handling the capturing element.
The others are BrowserChild::RecvRealMouseMoveEvent and
BrowserChild::RecvRealTouchMoveEvent. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
WidgetPointerHelper::convertToPointerRawUpdate member to check it in
PresShell::HandlePrecedingPointerRawUpdate.
Differential Revision: https://phabricator.services.mozilla.com/D243404
This patch just defines the event message, an atom for event listener attribute
and managing whether the window may have a listener.
Differential Revision: https://phabricator.services.mozilla.com/D243403
This patch tries to dispatch `ePointerRawUpdate` with
`PresShell::EventHandler::DispatchPrecedingPointerEvent` as same as usual
pointer events.
For using the path, this patch adds 2 internal events, `eMouseRawUpdate`
and `eTouchRawUpdate` which are never dispatched into the DOM because
`PresShell::EventHandler::DispatchPrecedingPointerEvent` will return `false`
for that and then the caller will stop handling the internal events.
There are 3 dispatchers of the internal raw update events.
One is `PresShell::EnsurePrecedingPointerRawUpdate()`. This dispatches the
internal event if and only if the coming event of `PresShell::HandleEvent` will
cause `ePointerMove`. The reason why `PresShell::HandleEvent` handles the
preceding raw-update event is, we should support `ePointerRawUpdate` events
for synthesized events for tests (in-process ones) and in the main process.
Additionally, if a `pointerrawupdate` event may destroy the target `<iframe>`.
In such ase, the following `pointermove` may need to be dispatched on its parent
window or another `<iframe>` window. Therefore, we need to dispatch the
internal raw update event before considering the target window (`PresShell`) and
handling the capturing element.
The others are `BrowserChild::RecvRealMouseMoveEvent` and
`BrowserChild::RecvRealTouchMoveEvent`. They dispatch the internal events
when they won't dispatch the received event immediately to coalesce with further
similar input.
For avoiding to dispatch the internal event for same source event, this adds
`WidgetPointerHelper::convertToPointerRawUpdate` member to check it in
`PresShell::HandlePrecedingPointerRawUpdate`.
Differential Revision: https://phabricator.services.mozilla.com/D243404
This patch just defines the event message, an atom for event listener attribute
and managing whether the window may have a listener.
Differential Revision: https://phabricator.services.mozilla.com/D243403
I'm not sure why the pen input causes running `CoalescedMouseData::Coalesce`,
but according to the bug report, it runs actually.
This patch adds a new method to `WidgetMouseEventBase` to compute it from
`mPressure` and `mButtons` and make both `CoalescedMouseData::Coalesce` and
`PointerEventHandler::InitPointerEventFromMouse` use it.
Differential Revision: https://phabricator.services.mozilla.com/D241530
`screenX`, `screenY`, `clientX`, `clientY`, `x`, `y`, `offsetX` and `offsetY`
are now `double`. This patch makes the event classes aware of DOM events.
Currently, Chrome allows fractional values only for pointer events whose type
is not `click`, `auxclick` nor `contextmenu` (this exception is defined by the
Pointer Events spec). Therefore, this patch follows them.
I'm not sure about the untrusted events of non-pointer events, `click`,
`auxclick` and `contextmenu`. Chrome does check whether it's trusted or not
before applying `std::floor` or `std::round` at getter methods (I think that
using `std::round` in `offsetX` and `offsetY` is their bug at least for
untrusted events). This patch follows them for now but has a pref to allow
for all untrusted events.
Finally, for aligning to Chrome, this patch makes `click`, `auxclick` and
`contextmneu` keep using integer coordinates because it's recommended by the
Pointer Events spec.
Note that this changes the logic in `Event::GetPageCoords`. It rounded the
client point and scroll point before adding them. Similarly,
`Event::GetOffsetCoords` too. It rounded the client point before transforming
it. Therefore, in strictly speaking, this changes the behavior of other events
which keep returning integer coordinates. However, I don't see any issues in
our CI. So, for making the code simpler, let's use it and once we got some
regression reports caused by this, let's make them take additional param to
round the points to integer done in the traditional code.
Differential Revision: https://phabricator.services.mozilla.com/D222728
Sends OOP drop events to content analysis for approval before sending them to
the DOM. It intercepts drop events at the browser level and sends them to CA
before calling stopPropagation and preventDefault on them. (CA also presents a
modal dialog over the tab.) The drag session then ends as usual in the parent
process but remains open on the related browser in the process where it would be
sent to the DOM while the drop is being analyzed. While CA runs, the browser
dispatches an eQueryDropTargetHittest event to locate the drop target while the
event screen coordinates are still valid. When CA is complete, a drop or
dragexit event is sent to the drop target (drop if it was approved by CA). Calls
to EndDragSession are delayed during this.
Differential Revision: https://phabricator.services.mozilla.com/D219201
- This patch separates RFPTarget::PointerEvents into PointerEvents and PointerId.
- PointerId protection is disabled for Android.
- WidgetEvents emit non-primary mouse events on Android because any touch other than 1nd touch is considered non-primary
- Sets maximum touch points to 5 on Android
Differential Revision: https://phabricator.services.mozilla.com/D221241
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
Currently, we set `tiltX` and `tiltY` on Windows, macOS and Linux. However,
they don't let us know the new values directly. Therefore, they are required
only for the DOM `PointerEvent`.
Differential Revision: https://phabricator.services.mozilla.com/D219128
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
When event target frame is destroyed, `PresShell::NotifyDestroyingFrame` updates
current event target content to the frame content. However, event target of
some DOM events need to be `Element`. Therefore,
`PresShell::mCurrentEventTarget` needs to store at least the handling
`EventMessage` to consider whether the event target can be non-element content
node or only element node. So, we need to make `PresShell::EventTargetInfo`
store `EventMessage`. Then, we can make `PresShell::NotifyDestroyingFrame`
prefer inclusive ancestor element as new event target from the `EventMessage`.
Although I don't understand what's going on the reported case, but I found the
simple case when event target is changed to a `Text` with the assertion in
`PresShell::DispatchEventToDOM`. Therefore, this patch has a new test.
Note that if target frame is a frame for element, e.g., when event target is
a focused element, `IsForbiddenDispatchingToNonElementContent` result won't
change the behavior. Therefore, its implementation is not optimized for
non-user input events.
Differential Revision: https://phabricator.services.mozilla.com/D217205
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
`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
Masayuki Nakano