In bug 1895870 I (somewhat unintentionally) made this code not called at
all.
Instead of scheduling a 30ms timer if reflow was interrupted, we just
schedule a reflow for the next refresh driver tick via
EnsureLayoutFlush(). Which is what would happen anyways before my change
in presence of other changes (like page loading appending content or
what not).
I think thus that the new behavior is more predictable (the 30ms timer
was never quite measured, it was introduced in bug 499447).
So, just simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D210890
Move `SetRootFrame()` to nsFrameManager.cpp, because in order to compile
`mRootFrame = aRootFrame` the compiler requires the full definition of
`ViewportFrame` to know that `ViewportFrame` is a subclass of `nsIFrame`
Differential Revision: https://phabricator.services.mozilla.com/D210671
We can just use `mFrameConstructor` to call `GetRootFrame()`. In order to do so
while keeping `PresShell::GetRootFrame()` as a inline method, we need to include
`nsCSSFrameConstructor` header in `PresShell.h`, and remove `PresShell` header
in `nsCSSFrameConstructor.h`. That means we can no longer inline
`RestyleManager()` since it needs to access `PresShell`, but it's OK since
`RestyleManager` is used only in the frame constructor, and is probably not in
the hot path.
Differential Revision: https://phabricator.services.mozilla.com/D210670
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
Query content is used for a part of handling user interaction with IME or
query request from IME via native API. Therefore, we don't need to flush
pending things at that time since it's not the last chance to do so before
handling next user input. Additionally, the call may cause same query before
returning the result to IME so that may cause stack overflow crash and
that means we flush layout even if the query request does not want flushing
pending things. Therefore, we should not do that at handling query content
event.
Differential Revision: https://phabricator.services.mozilla.com/D209990
The Pointer Events spec defines that:
> Authors can prevent the firing of certain compatibility mouse events by
> canceling the pointerdown event (if the isPrimary property is true).
> <snip>
> Note, however, that this does not prevent the mouseover, mouseenter, mouseout,
> or mouseleave events from firing.
https://w3c.github.io/pointerevents/#the-pointerdown-event
The other browsers conform to this. Therefore, we should stop dispatching
compatibility mouse events only if the preceding `pointerdown` is consumed by
content. I.e., we need to keep dispatching touch events and `click` etc which
indicate what should happen on the element.
Currently, `APZEventState` does not manage whether the preceding `pointerdown`
is canceled or not. So, it dispatches compatibility mouse events via
`APZCCallbackHelper` after the consumed pointer is removed. Therefore, we
need to make it manage whether the preceding `pointerdown` of the first touch
is consumed or not and `APZCCallbackHelper` needs an option to dispatch the
compatibility mouse events only to chrome (they are required to dispatch
`click` etc).
However, if `APZEventState` is not available like test API used in the
remote process, `TouchManager` needs to manage it instead of `APZEventState`.
I don't think only `TouchManager` should manage it because `APZEventState`
manages complicated state of touch gestures and that can know whether the
synthesizing compatibility mouse events related to the consumed `pointerdown`
or not strictly. Therefore, this patch makes the `TouchManager` state used
only in the path handling synthesized events for tests.
Differential Revision: https://phabricator.services.mozilla.com/D208706
A version of the patch in bug 1895870 caused some WPT tests to time out
because document.fonts.ready never resolves.
This is because I made PresShell::HasPendingReflow look at
mNeedLayoutFlush, and nsIFrame::SchedulePaint() calls
PresShell::ScheduleViewManagerFlush() which sets that bit.
So we end up with mNeedLayoutFlush, but without a flush scheduled, and
the ready promise doesn't resolve until something else schedules a
flush. I fixed the original patch to preserve behavior, but requesting a
repaint shouldn't require a layout flush.
This call was added in bug 598482 part 16:
https://hg.mozilla.org/mozilla-central/rev/71d77495b606fc145bdceabcda29181978bd9405
We only need the layout flush if there are view geometry updates, so
shift the call up to the view manager.
Differential Revision: https://phabricator.services.mozilla.com/D209938
Instead of relying on the embedder color-scheme directly, use the
color-scheme property to determine the nsCocoaWindow's appearance.
This is more in line with what content does, would've prevented this bug
from existing altogether, and avoids the need for MOZGlobalAppearance.
Differential Revision: https://phabricator.services.mozilla.com/D207050
We should continue to use a wheel transaction for wheel events when the
browsing context changes from the current context. Avoiding the override
of the event target with the current wheel transaction can halt a page
scroll when the mouse moves over content in a different presentation
context.
Differential Revision: https://phabricator.services.mozilla.com/D205495
The reason I want to rename this so that it is clear that it is intended for tests only is for bug 1866411. If we see that this pref is set then we can assume that it isn't being flipped during the loading of images, and therefore we can avoid the extra invalidates that sync decode paints would normally incur.
Differential Revision: https://phabricator.services.mozilla.com/D208111
We should continue to use a wheel transaction for wheel events when the
browsing context changes from the current context. Avoiding the override
of the event target with the current wheel transaction can halt a page
scroll when the mouse moves over content in a different presentation
context.
Differential Revision: https://phabricator.services.mozilla.com/D205495
This patch integrates the algorithm to find a text fragment range
into the document loading mechanism.
Unlike described in the spec, the fragment directive is not stripped
from the URL in the Session History Entry, instead it is stripped when
setting the URI into the Document using `Document::SetURI()`,
as well as when accessing the URL through `Location`.
The `PresShell` class is extended by a new method which sets the
ranges created from the text directives into the FrameSelection as
TargetText selection and scrolls it into view.
Security restrictions like force load at top and cross-origin iframes
are not yet considered in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D195688
This patch integrates the algorithm to find a text fragment range
into the document loading mechanism.
Unlike described in the spec, the fragment directive is not stripped
from the URL in the Session History Entry, instead it is stripped when
setting the URI into the Document using `Document::SetURI()`,
as well as when accessing the URL through `Location`.
The `PresShell` class is extended by a new method which sets the
ranges created from the text directives into the FrameSelection as
TargetText selection and scrolls it into view.
Security restrictions like force load at top and cross-origin iframes
are not yet considered in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D195688
In particular:
* Always handle meta viewport in RDM. This fixes bug 1625999 too by
making touch simulation enabled and disabled consistent.
* Restore the resolution to 1 when toggling RDM. This is just simpler,
and we're not keeping around the visual viewport offsets anyways
so...
* Deal with the change more easily, at the same point we switch
scrollbars etc.
Differential Revision: https://phabricator.services.mozilla.com/D206266
This patch integrates the algorithm to find a text fragment range
into the document loading mechanism.
Unlike described in the spec, the fragment directive is not stripped
from the URL in the Session History Entry, instead it is stripped when
setting the URI into the Document using `Document::SetURI()`,
as well as when accessing the URL through `Location`.
The `PresShell` class is extended by a new method which sets the
ranges created from the text directives into the FrameSelection as
TargetText selection and scrolls it into view.
Security restrictions like force load at top and cross-origin iframes
are not yet considered in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D195688
This patch integrates the algorithm to find a text fragment range
into the document loading mechanism.
Unlike described in the spec, the fragment directive is not stripped
from the URL in the Session History Entry, instead it is stripped when
setting the URI into the Document using `Document::SetURI()`,
as well as when accessing the URL through `Location`.
The `PresShell` class is extended by a new method which sets the
ranges created from the text directives into the FrameSelection as
TargetText selection and scrolls it into view.
Security restrictions like force load at top and cross-origin iframes
are not yet considered in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D195688
The caret position is in the DOM, and sometimes can get out of sync.
While that is an issue, it's not new: The code before the regressing bug
papered over it on a pre-pass before entering DL building.
Instead, deal with it using MarkFramesForDisplay (just like we mark the
caret frame itself, which has the same issue), and invalidate the old
frame more precisely by tracking it in nsCaret directly.
Also, add missing invalidation in PresShell::SetCaret, where the caret
might change and the old caret might not be invalidated properly.
Differential Revision: https://phabricator.services.mozilla.com/D205369
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
