Before this patch, it could happen that `PresShell::GoToAnchor()` was called while loading a document.
This method did not know about text fragments before,
and would scroll the anchor (ie., the first text directive) to the top of the view.
This was noticeable for pages that took longer to load, where the text directive was scrolled to the center first, and then to the top.
This patch saves the desired vertical scroll position as a member in `PresShell` and makes `GoToAnchor()` scroll to the center as well.
Additionally, this patch updates the test file target document to make it more mobile-friendly.
Differential Revision: https://phabricator.services.mozilla.com/D216039
Since container is transformed, container->GetTransformMatrix will always just put the cross doc parent frame into parent. I checked the history when this code was written, it looks like GetTransformMatrix (via GetResultingTransformMatrix) might have go up more than one parent frame in the case of preserve 3d (combines 3d) frames. That is no longer the case, and GetTransformMatrix is a relatively heavyweight function.
Differential Revision: https://phabricator.services.mozilla.com/D215860
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
This patch makes some adjustments to follow the spec more strictly by
separating highlighting a text fragment (ie. adding the ranges to a `eTargetText` Selection)
from scrolling to it.
Scrolling to the text fragment now follows the steps given in [0] more closely,
in particular now the closest common ancestor of the target range is being used
as `:target` element.
This change also sets the focus to the start of the first text fragment, as indicated by the spec.
This resets the normal selection on the page.
The wpt test in /css/css-pseudo/target-text-005.html is based on the idea of having a same-doc
text fragment navigation with a selection.
This test fails with this patch applied, because the selection is reset.
It is currently unclear what behavior is correct here, thus the test is kept for now.
[0]: https://wicg.github.io/scroll-to-text-fragment/#invoking-text-directives
Differential Revision: https://phabricator.services.mozilla.com/D211025
This patch makes some adjustments to follow the spec more strictly by
separating highlighting a text fragment (ie. adding the ranges to a `eTargetText` Selection)
from scrolling to it.
Scrolling to the text fragment now follows the steps given in [0] more closely,
in particular now the closest common ancestor of the target range is being used
as `:target` element.
This change also sets the focus to the start of the first text fragment, as indicated by the spec.
This resets the normal selection on the page.
The wpt test in /css/css-pseudo/target-text-005.html is based on the idea of having a same-doc
text fragment navigation with a selection.
This test fails with this patch applied, because the selection is reset.
It is currently unclear what behavior is correct here, thus the test is kept for now.
[0]: https://wicg.github.io/scroll-to-text-fragment/#invoking-text-directives
Differential Revision: https://phabricator.services.mozilla.com/D211025
`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
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
The debug statements all require customized #define to enable. I don't feel it
is useful to leave code that is not compiled in the default debug build.
Differential Revision: https://phabricator.services.mozilla.com/D212192
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
This patch starts from renaming `PresShell::GetScrollableFrameToScroll()` to
`PresShell::GetScrollContainerFrameToScroll()`, making it return
`ScrollContainerFrame*`, and then fixing other helpers until everything
compiles. As before, we can remove some `do_QueryFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211491
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
This patch starts from renaming `PresShell::GetScrollableFrameToScroll()` to
`PresShell::GetScrollContainerFrameToScroll()`, making it return
`ScrollContainerFrame*`, and then fixing other helpers until everything
compiles. As before, we can remove some `do_QueryFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211491
In theory, changing the return type from `nsIFrame*` to `ScrollContainerFrame*`
exposes `ScrollContainerFrame` to the callers who might not needed, but almost
all of the callers in cpp files are already exposed to `nsIScrollableFrame`, as
demonstrated in this patch via replacing the #include from
"nsIScrollableFrame.h" to "ScrollContainerFrame.h", so this is OK.
Some callers can be simplified since we no longer need `do_QueryFrame` to
`nsIScrollableFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D211488
This telemetry was trying to measure three things:
* The time spent during style / layout in a tick. This is useful.
* The times SetNeed{Style,Layout} flush have been called. This is not a
particularly useful metric, there's not much to learn or change from
it. Any call is basically free as long as they're consecutive /
there's no flush in between.
* The number of times layout / style has been flushed during a tick.
This is more useful than the above but, similarly, there's not too
much to be learned here. Number of flushes can be completely
orthogonal to how expensive it has been.
It also had a number of flaws:
* It is recorded per-PresShell, so we get multiple pings per tick.
* Similarly, if a sub-frame dies before the tick, we just never report
that time.
Instead, refactor it to make it simpler, and just record the first
metric reliably. This simplifies the code substantially, and I don't
think we're losing much.
The histograms are also expired. We might want to renew this, I'll file
a follow-up to either properly renew this if we plan to look at it, or
remove the code entirely from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D210907
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
