Currently, we don't dispatch synthesized `ePointerMove` unless it's
required for dispatch the boundary events after dispatching
`ePointerLostCapture` event [1] since Pointer Events defined that the
boundary events should be fired only when before dispatching a pointer
event. However, it's changed, Point Events currently defines that the
boundary events should be fired if the element under the pointer is
changed without a `pointermove` [2] if and only if the pointer supports
hover.
Therefore, this patch makes `PresShell` store the last input source
whose event set the mouse location at last and
`PresShell::ProcessSynthMouseMoveEvent()` sets the input source to make
`PointerEventHandler::DispatchPointerFromMouseOrTouch()` can consider
whether it needs to dispatch pointer boundary events or not for the
pointer.
Additionally, the mochitests for the manual WPTs under
`dom/events/test/pointerevents` checks `pointerId`. Therefore, this
patch makes `PresShell` also store the last `pointerId` and set it to
the synthesized `eMouseMove` too.
I think that this approach is **not** correct approach to fix this bug
because there could be multiple hoverable pointers, but we synthesize
pointer boundary events only for the last input device. I think it's
enough for now because we've not supported pen well (we've not supported
the test API yet!), so, we only support only mouse input well as
hoverable inputs. I think we should extend `PointerInfo` and make a
synthesizer of `ePointerMove` later.
Note that this patch changes 2 WPTs which both are in the scope of
Interop.
The expectation of
`pointerevent_pointer_boundary_events_after_removing_last_over_element.html`
needs to be changed for conforming to the latest spec. I wrote this
test before the spec change and it wasn't updated when the spec is
changed. I filed this issue to interop [3].
The changes for `pointerevent_pointerout_no_pointer_movement.html` is
required for avoiding the timeout. Gecko does not allow recursive
synthesized `eMouseMove` to prevent infinite reflow loops without moving
the mouse cursor. However, the test expects that and that causes
requiring the hack for Chrome too. Therefore, I split the test to
make each step run in different event loop and I removed the hack for
Chrome.
Note that this patch also removes 2 sets of mochitests for WPT manual
tests because they are now tested with the test driver [4][5] and they
fail without maintained.
1. https://searchfox.org/mozilla-central/rev/f571db8014431de31d245017e2f5457046aec4ea/dom/events/PointerEventHandler.cpp#494-503
2. https://w3c.github.io/pointerevents/#boundary-events-caused-by-layout-changes
3. https://github.com/web-platform-tests/interop/issues/961
4. https://wpt.fyi/results/pointerevents/pointerevent_boundary_events_in_capturing.html%3Fmouse?label=master&label=experimental&aligned&view=interop
5. https://wpt.fyi/results/pointerevents/pointerevent_releasepointercapture_events_to_original_target.html%3Fmouse?label=master&label=experimental&aligned&view=interop
Differential Revision: https://phabricator.services.mozilla.com/D250421
The assertion was intended to detect unexpected recursive event dispatching of
`ePointerRawUpdate`. However, if may occur if spinning the event loop with
opening a modal dialog or synchronous XHR. Therefore, the assertion may fail
even in the valid situations.
The crash reports are caused by synthesized `eMouseMove`. However, it'll be
checked after getting `WidgetMousePointer*` after the removing assertion.
So, the case is correctly handled anyway.
Differential Revision: https://phabricator.services.mozilla.com/D249871
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 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
We'll need to compute the target `PresShell` before processing the pending
pointer capture to check whether the corresponding window needs
`pointerrawupdate` events (bug 1550462).
However, current code needs to process the pending pointer capture.
Unfortunately, if we process the pending pointer capture at considering whether
we need to dispatch `pointerrawupdate` event on the target `PresShell`, the
event order may be changed in some edge cases. For example, if web apps updates
the pointer capture element in a `gotpointercapture` or `lostpointercapture`
event listener, another processing of pending pointer capture will be done
before dispatching the following `pointermove`. So, there are two chances to
process pending pointer capture at dispatching `pointermove` and this may be
unexpected behavior change for the most web apps which do not use
`pointerrawupdate` event listener.
For keeping the traditional behavior on the most web apps which do not listen to
`pointerrawupdate`, we need a method to compute the target without processing
the pending pointer capture. However, it requires to return multiple nodes.
Therefore, this patch adds a new subclass of `EventTargetData` to return
multiple additional information within an `EventTargetData` from the new
computation method.
Differential Revision: https://phabricator.services.mozilla.com/D247252
Pointer Events defines the `click`, `auxclick` and `contextmenu` target as [1]:
> 1. Let event be the click, auxclick or contextmenu event being dispatched,
> and userEvent be the user interaction event that caused the firing of event.
> 2. If userEvent is not a PointerEvent, dispatch event following the [UIEVENTS]
> spec without overriding event target and skip the remaining steps below.
> 3. If event is a contextmenu event, or userEvent was dispatched while the
> corresponding pointer was captured, then let target be the target of userEvent.
`contextmenu` case is a little bit more complicated than `click` and `auxclick`
because it's always targeted to the `pointerup` target and we don't store the
`pointerup` target and `contextmenu` is usually triggered by the native
"contextmenu" event. Therefore, this patch fixes only the case if an element
captures the pointer at dispatching `pointerup`.
However, this standardized behavior is unfortunately different from the fixed
behavior of bug 1447993. In the bug, we made the target as the element under
the pointer which may be a descendant of the capturing element. Fortunately,
even after applying this patch, the reported web app works even though the
reported page has gone and the issue of the web app is still open. For making
things safer, this patch enables the new behavior only on early beta builds and
in the nightly channel for now to get the feedback from the testers.
`test_bug1447993.html` (and `window_bug1447993.html`) keeps testing the fix of
bug 1447993 with disabling the new behavior. Instead of the test, this patch
adds new WPT to check the standardized behavior in the same steps. Chrome
files to target to the capturing element at touch, but the developers agree
with it's unexpected behavior [2].
1. https://w3c.github.io/pointerevents/#event-dispatch
2. https://github.com/w3c/pointerevents/issues/508#issuecomment-2180813312
Differential Revision: https://phabricator.services.mozilla.com/D218275
This reverts commit 0681b181d6.
Revert "Bug 1932150 - Fix lint failure" for causing Build bustage.
This reverts commit 60cc0878d3.
Revert "Bug 1932150 - Add new test cases for selection in flat tree r=smaug"
This reverts commit 3dbe5fc183.
Revert "Bug 1932150 - Make selection code to correctly iterate flattened tree r=smaug"
This reverts commit 6f7a1e4886.
Revert "Bug 1932150 - ContentSubtreeIterator #3: Fix a bug in ContentSubtreeIterator where the end container is in the light DOM of a shadow host r=jjaschke"
This reverts commit 19ce2c5806.
Revert "Bug 1932150 - ContentSubtreeIterator #2: Allow ContentSubtreeIterator to iterate nodes in flattened tree r=jjaschke"
This reverts commit d9d192bc3a.
Revert "Bug 1932150 - ContentSubtreeIterator #1: Make the end container related logic in ContentSubtreeIterator more robust r=jjaschke,smaug,dom-core"
This reverts commit 2fbde5b84d.
Revert "Bug 1932150 - Update ranges to correctly set and update nodes for flattened selection r=jjaschke,smaug,dom-core"
This reverts commit 116d26c37f.
Revert "Bug 1932150 - Allow using flat tree order for point comparing in selection r=jjaschke,smaug,dom-core"
This reverts commit 2ba73e1639.
Revert "Bug 1932150 - Fix some inconsistency about indicating whether the selection is allowed to cross the shadow boundary r=jjaschke,dom-core"
This reverts commit 793c2453f1.
In order to do this and keep tests passing, we need to also recurse into
external resource docs during the refresh driver tick.
Otherwise, we fail dom/smil/test/test_smilExtDoc.xhtml. This used to
work because the SMIL controller registered with the refresh driver
directly, and resource docs share the refresh driver with the parent
doc. I think it makes sense to treat them more like subdocuments, and it
also matches svg-as-image better.
This fixes some known SMIL bugs, too, yay.
Differential Revision: https://phabricator.services.mozilla.com/D246588
In order to do this and keep tests passing, we need to also recurse into
external resource docs during the refresh driver tick.
Otherwise, we fail dom/smil/test/test_smilExtDoc.xhtml. This used to
work because the SMIL controller registered with the refresh driver
directly, and resource docs share the refresh driver with the parent
doc. I think it makes sense to treat them more like subdocuments, and it
also matches svg-as-image better.
This fixes some known SMIL bugs, too, yay.
Differential Revision: https://phabricator.services.mozilla.com/D246588
Otherwise we can end up with dirty frames at the end of a flush. This
doesn't fix bug 1958522 (I think we need either height: fit-content to
work, or IntersectionObserver.scrollMargin). But matches the HTML spec:
> The intent of this step is for the initial viewport proximity
> determination, which takes effect immediately, to be reflected in the
> style and layout calculation which is carried out in a previous step of
> this loop. Proximity determinations other than the initial one take
> effect at the next rendering opportunity.
Differential Revision: https://phabricator.services.mozilla.com/D245489
Run it in the right step of the rendering loop as per spec. Keep
the interruptible layout behavior by detecting whether we have any
frame with content-visibility: auto / ResizeObserver / etc around.
Also make the IntersectionObserver phase not unconditional, make it
conditional on needing layout or having scrolled.
I want to look a bit whether we can avoid flushing the whole browsing
context tree, but that is pre-existing so not touching it as part of
this work.
Differential Revision: https://phabricator.services.mozilla.com/D245214
This reuses the newly introduced infrastructure to track painting, and
avoids painting if rendering is suppressed (such as for view transitions
and so on).
Rendering suppression of an in-process iframe needs more work because
right now we paint in-process iframes as part of the top document's
display list.
Remove some old paint invalidation printf-debugging, which I suspect
nobody has used in years. Profiler markers are strictly better :)
Differential Revision: https://phabricator.services.mozilla.com/D245063
Deal with events per-document like the spec. This also ensures that view
transition rendering suppressions and such work for this rendering
phase.
Differential Revision: https://phabricator.services.mozilla.com/D244670
This makes regular and visual viewport event handling happen as per
spec, on a per-document basis, in the same order as all the other
rendering steps. This is very easy to do after bug 1958942.
Note we don't need to deal with "delayed" events by hand now. Now those
are dealt with via the "rendering suppression" mechanism
Document::IsRenderingSuppressed() will return true when events are
suppressed, and schedule another rendering update when unsuppressed if
needed.
Differential Revision: https://phabricator.services.mozilla.com/D244655
This starts some of the needed refactoring towards having proper
rendering suppression, and in general aligning better with the HTML
spec's "update the rendering" section.
Behavior changes should be minimal:
* We suppress rendering until the pres shell is initialized rather than
just created. This matches how autofocus already works and in general
we don't want to forcibly flush an uninitialized presshell.
* We handle view transition suppression more correctly in some (but not
all) phases.
* Some of the steps do no longer recurse manually nor check the view
transitions suppression, as that's done centrally.
* mAutoFocusFlushDocuments isn't tracked separately.
Follow-up work will involve changing most of the "pending resize/scroll/etc"
events to be per-document as per spec, and also implement suppression for
painting.
Differential Revision: https://phabricator.services.mozilla.com/D244372
Since last time we tried this:
* A lot of internal usage has gone away.
* They have been successfully been unshipped from content and
extensions.
So we should try this again.
Differential Revision: https://phabricator.services.mozilla.com/D5271
For safety, both of helper_scrollIntoView_bug1950744.html and
helper_scrollIntoView_bug1950744-2.html run with
layout.scroll_fixed_content_into_view_visually=true and
layout.scroll_fixed_content_into_view_visually=false because these tests
should NOT cause any scrolling regardless of the pref value.
Differential Revision: https://phabricator.services.mozilla.com/D243735
The main goal of this patch is to ensure that we render the snapshots as
soon as the transaction is received on the WebRender to prevent another
transaction within the same vsync interval from replacing the old
state's transaction before it has had a chance to produce the snapshots.
In addition, we produce the snapshots by generating a frame that isn't
presented to the window. This is to avoid potential vsync issues from
trying to present multiple times in the same interval and avoids a fair
amount of wasted work.
Differential Revision: https://phabricator.services.mozilla.com/D242358
Always paint the scrolled canvas background if it's CSS-specified.
Compute the canvas background upfront so we don't need to walk the
display list after the fact.
This removes the scrolled canvas background in a few cases where the old
code could prove that it was not needed due to blending, see the
comment:
// To make layers work better, we want to avoid having a big non-scrolled
// color background behind a scrolled transparent background. Instead, we'll
// try to move the color background into the scrolled content by making
// nsDisplayCanvasBackground paint it.
It's unclear if that matters for performance with webrender nowadays,
but removing it does cause significant fuzzy failures, so it will be
reintroduced in a more explicit way in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D242017
