Firefox never uses this. TB could use the same approach Firefox uses,
but for now on macOS the sheets become regular modal dialogs, which is
the same as on Windows and Linux.
See bug 1755330 and bug 1737489 for more context.
Differential Revision: https://phabricator.services.mozilla.com/D204209
As far as investigating the behavior of the other browsers, touch events are
dispatched the same target as the preceding `pointerdown` even after the target
is removed from the DOM tree. However, the following pointer events are
dispatched on the target as usual (i.e., the element under the pointer except
when the pointer is captured). However, our code stops handling touch events
if the preceding `pointerdown` removes the target and not dispatching
`touchstart` causes not dispatching the following touch events so that no
`click` event is fired.
This patch makes the touch event dispatching path work without frame and
keep handling even with an orphan event target.
Differential Revision: https://phabricator.services.mozilla.com/D202811
The reason of the bug is, no `mouseup` event is fired after the `pointerup`
event listener removed the target. Therefore, `nsIFrame::HandleRelease()` does
not run and nobody cleans up the drag state of the `nsFrameSelection`.
This is caused by that `PresShell::EventHandler::DispatchPrecedingPointerEvent()`
updates only event target frame of the following mouse event target if the
pointer event target was removed from the tree, however, the frame may not be
ready. In this case, `PresShell::GetCurrentContent()` will clear both current
event target content and frame because its composed document (`nullptr`) never
matches with the document for the `PresShell`. Therefore, it needs to update
the target too.
This patch makes all developers won't create similar bugs, this encapsulate
`EventTargetData::mContent` and `EventTargetData::mFrame` to make their setters
clean up or automatically check the relation.
Differential Revision: https://phabricator.services.mozilla.com/D201053
`mouse_boundary_events_after_removing_last_over_element.html` expects that
a `mouseover` should be fired between `click` and `mousemove`, but it's
dispatched by a synthetic mouse move event caused by removing the click target.
The fix of bug 1864654 tried to fix this kind of issues, but it does not flush
pending event at `eMouseMove`. Therefore, the synthetic mouse move may not be
handled before handling `eMouseMove` which is caused by `pointerMove()` in the
test.
I guess that we need to make it flush before all events which are directly
caused by a user input. However, I don't want to do it for now because of
the risk.
Depends on D199607
Differential Revision: https://phabricator.services.mozilla.com/D199694
`inert-iframe-hittest.html` expects that `:hover` state should be updated
immediately after a pointer down. The state is updated by
`EventStateManager::NotifyMouseOver` [1] when we received a real or synthetic
`eMouseMove`. Therefore, the hover state may have not set yet if no refresh
occurs between the pointer down and checking the result.
Additionally, some WPT for UI Events and Pointer Events expect that `mouseover`
or `mouseout` should be fired before `mouseup`/`pointerup` if a preceding
`mousedown` or `pointerdown` event listener removes the target. So, this
patch may fix intermittent failures of them if there are.
Therefore, we should flush pending synthetic `mousemove` event for keeping the
event order as same as they happen. However, simply flushing it causes
unexpected pointer capture state change because
`PointerEventHandler::ProcessPointerCaptureForMouse` handles synthetic
`mousemove` but it should not cause pointer boundary events at the moment (the
pointer boundary events should be fired when the pointer is actually moved, note
that this is different rule from the rules of mouse boundary events).
Therefore, this patch changes
`PointerEventHandler::ShouldGeneratePointerEventFromMouse`.
However, this blocks `lostpointercatpure` event when the capturing content has
already been removed from the DOM tree. The path is,
`EventHandler::HandleEventWithPointerCapturingContentWithoutItsFrame` stops
dispatching `pointerup` nor `pointercancel` in this case, but
`EventStateManager::PostHandleEvent` is the only handler of implicit pointer
capture release. Therefore, we need to make it dispatch lostpointercatpure`
event if the canceling event caused `ePointerUp` or `ePointerCancel`.
Finally, this patch fixes a bug of `browser_ext_browserAction_popup_preload.js`.
It tests the pre-loading which starts when `mouseover` before `mousedown` on a
widget. However, it does not correctly emulate the user input.
* Synthesizing only `mouseover` does not update the internal pointer info and
does not cause dispatching related events.
* Synthesizing `mousedown` without `mousemove` cause `mouseover` before
`mouseup` because at dispatching `mousedown`, `PresShell` stores the cursor [2]
and the mouse boundary events will be dispatched before `mouseup`.
`ext-browserAction.js` assumes the events are fired as this order,
`mouseover` -> `mousedown` -> `mouseup`, but this would not work if the
preceding `mousemove` of `mousedown` is not correctly fired. I'm not sure
whether `mousemove` is always fired before `mousedown` on any environments,
but it should be rare and it affects only this kind of tricky code. For now,
fixing this in the test side must be enough.
1. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/dom/events/EventStateManager.cpp#4874,4913-4914
2. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/layout/base/PresShell.cpp#6756
Differential Revision: https://phabricator.services.mozilla.com/D193870
Right now, we reconstruct frames in response to a change in the CSS
`contain` property or `content-visibility`. This patch tries to optimize
this a bit:
1. Updates involving style containment change continue to force a
reconstruction, due to the need to handle counters/quotes.
2. Updates involving paint/layout containment change only force a
reconstruction if it's needed to handle absolutely/fixed
positioned descendants or floats (for this one, see also bug 1874826).
3. Other containment changes will only force a reflow and repaint.
Per the CSS contain spec, layout, style and paint containments are
enabled for `content-visibility: hidden` and `content-visibility: auto`.
As a consequence, changing `content-visibility` between `hidden` and
`auto` values no longer requires reconstruction. Changing between these
values and `visible` may need a reconstruction although authors may
generally avoid that in practice by forcing `style` containment.
Differential Revision: https://phabricator.services.mozilla.com/D197043
This can run script, and as such shouldn't run from a container query
update. Instead, let's move the check to DidDoReflow, which deals with
that appropriately already.
I don't know of an easy / reliable way to reproduce this, since paint
unsuppression is very timing-dependent.
While at it, remove the long reflow telemetry check for
GetRootElement(). This comes from a time where we used the root
element's namespace to determine which telemetry counter to use.
Differential Revision: https://phabricator.services.mozilla.com/D197477
When the line scroll amount is larger than that of the rectangle to
scroll into view, do not use the line size to determine if we should
scroll.
Depends on D192869
Differential Revision: https://phabricator.services.mozilla.com/D192870
-moz-window-shadow is a chrome-only property (not exposed to the web),
and chrome stylesheets only use the none value to disable the default
behavior.
Split the style property (default/none) from the actual widget behavior.
This is useful because I want to add a distinction between
natively-styled menupopups and other panels in the following commit.
While at it rename default to "auto" which is a more common name in CSS
for something like this.
We have no use case for removing the shadow of a top-level window, so
remove it to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D197454
Currently, the method ignores synthesized `eMouseMove` events coming from the
parent process if
* the last mouse location was updated by a synthesized mouse event for tests
* the event comes from parent process
* the event is not marked as synthesized for tests
However, `eMouseExitFromWidget` is also handled as a synthesized `eMouseMove` [1].
Therefore, the method needs to ignore this event too in the same conditions.
Additionally, `eMouseEnterIntoWidget` may cause updating the `:hover` state
under the event position which may be different from the last cursor position
in the content process [2]. Therefore, the method needs to ignore this too.
On the other hand, if the event is caused by a test API synthesizing mouse
events, e.g., when `test.events.async.enabled` is set to `true`, the running
test must expect the events. Therefore, these events need to be marked as
synthesized for tests correctly. Therefore, this patch updates the
initializers of the events.
1. https://searchfox.org/mozilla-central/rev/78a2c17cc80680a5a82446e4ce7c45a73b935383/dom/events/EventStateManager.cpp#773,794-796,800-801
2. https://searchfox.org/mozilla-central/rev/78a2c17cc80680a5a82446e4ce7c45a73b935383/dom/events/EventStateManager.cpp#4063,4068
Differential Revision: https://phabricator.services.mozilla.com/D195638
Implement experimental transparent-on-hover behavior for the
picture-in-picture video player. This makes the popup player less of
a nuisance on smaller displays.
Tested on macOS, but should also work on Windows with small tweaks.
The behavior is hidden behind a pref:
media.videocontrols.picture-in-picture.seethrough-mode.enabled
Differential Revision: https://phabricator.services.mozilla.com/D193993
When the line scroll amount is larger than that of the rectangle to
scroll into view, do not use the line size to determine if we should
scroll.
Differential Revision: https://phabricator.services.mozilla.com/D192870
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This fixes the flash mentioned in bug 1858405 comment 6.
I don't think this is realistically testable tho, since this is only for
non-content-accessible, temporary documents (if you load about:blank
directly that's not an initial doc).
Differential Revision: https://phabricator.services.mozilla.com/D194246
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
