This is mostly a revert of the patch in bug 1425686 that removed the old
probe, but rebased to new code locations and clang-formatted. The histogram
entry is also updated with new bug numbers and fields.
The next patch will refine some of these telemetry recording points; the patch
is split into two for easier reviewing as this part is basically what landed
originally.
Differential Revision: https://phabricator.services.mozilla.com/D92995
when there is no composition, `IMEStateManager::HandleSelectionEvent()` calls
`TextComposition::HandleSelectionEvent()` with `BrowserParent` which is
retrieved from `aEventTargetContent` which is focused content in the main
process. This means that `eSetSelection` event is handled in root document
of the focused tab when there is no composition. However, following composition
events will go to focused `BrowserParent`, i.e., if an OOP iframe has focus
in the tab, `eSetSelection` event won't be handled in it. Therefore, IME
always fails to replace existing text with new composition.
This patch makes both `IMEStateManager::HandleSelectionEvent()` and
`PresShell::EventHandler::DispatchEventToDOM()` use
`IMEStateManager::GetActiveBrowserParent()` for sending both `eSetSelection`
and composition events to same process. Additionally, this patch make
`IMEStateManager::GetActiveBrowserParent()` returns
`IMEStateManager::sFocusedIMEBrowserParent` when it's set to non-nullptr
because native IME tries to modify the editor which enabled IME context.
On the other hand, for making the behavior safer, we should make
`eCompositionStart` event have replacing range optionally. I filed
bug 1669907 to change the design, but it requires several non-tiny patches.
Once we fix it, we can write automated tests for this simply, but without
the fix, I need to write too many lines with low level API, and it becomes
unnecessary after fixing the bug. Therefore, I give up to write a test
for this for now.
Differential Revision: https://phabricator.services.mozilla.com/D93053
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
This patch tries to mark root callers of `nsINode::GetSelectionRootContent()`
which calls `nsINode::GetAnonymousRootElementOfTextEditor()` as far as possible
(and reasonable).
It's used by `ContentEventHandler` so that a lot of methods of
`EventStateManager`, `ContentEventHandler`, `IMEContentObserver` which are main
users of it are also marked as `MOZ_CAN_RUN_SCRIPT`. I think that this is
reasonable.
On the other hand, it might not be reasonable to mark `IMEStateManager` methods
as `MOZ_CAN_RUN_SCRIPT` for initializing `IMEContentObserver` because
`IMEStateManager` may be able to initialize `IMEContentObserver` asynchronously
and its root callers are in XUL layout code. Therefore, this patch uses
`MOZ_CAN_RUN_SCRIPT_BOUNDARY` for `IMEStateManager` at least for now.
Differential Revision: https://phabricator.services.mozilla.com/D92730
Where an adjustment (to reflect a delta between the APZ and layout
scroll offsets) is necessary, the inputs needed to compute the
adjustment are stored with the margins, and the adjustment is
applied at query time.
A couple of notes on this patch:
* Storing DisplayPortMargins::mLayoutOffset is probably unnecessary,
we should be able to just query the scroll frame's layout offset
when applying the margins.
* Some callers of DisplayPortMargins::WithNoAdjustment() may be
incorrect, in that they pass in margins that are relative to the
visual viewport but do not make a corresponding adjustment.
This is a pre-existing issue that this patch just makes clearer.
As this is a regression-prone area, this patch is careful to avoid
making any functional changes, leaving the above issues to be
addressed in future bugs.
Differential Revision: https://phabricator.services.mozilla.com/D92506
The audio/video controls element has touch listeners on the scrubber, which
steals events when we don't want it to. So let's ignore those listeners.
Ignoring system group listeners for the purposes of event retargeting seems
reasonable in the general case, because those listeners are coming from the
browser itself. If we're relying on the event retargeting to make those browser
elements easy to hit, then we should not be doing that and instead just make
them bigger.
Test coverage for this change is provided by the android-components tests that
failed in bug 1668112. The next patch re-enables touch event retargeting and
exercises this code in the context of those tests.
Depends on D92436
Differential Revision: https://phabricator.services.mozilla.com/D92437
The only caller passed in DisplayRelativeTo::ScrollFrame.
Removing this makes it easier to consolidate display port options
in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D92014
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
The frame we pass to PageMove is used to extend the selection, we can't extend a selection outside of the document. The scrolling that takes place can still scroll scroll frames in parent documents afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D92176
The math-depth implementation is refined to take into account the
ScriptPercentScaleDown and ScriptScriptPercentScaleDown constants (if the
parent's first valid font has a MATH table) in order to calculate the
scale factor between math-deth 0 and 1, and between 0 and 2 respectively.
Behavior is unchanged if the legacy scriptsizemultiplier attribute is
specified or if no MATH table is available.
The preference layout.css.math-depth.enabled remains disabled in nightly
until the remaining bit (support for font-size: math) is implemented in
bug 1667090.
Differential Revision: https://phabricator.services.mozilla.com/D91604
This patch fixes two issues, described below:
First, the GetTopLevelDocument function was looking at the browsing
context tree. It should look at the window context tree, as looking at
the browsing context tree means that if you're in a discarded or
about-to-get-discarded document, you can end up with a document from a
different tree. Computing intersections between those of course makes no
sense and triggers the assertion we're enabling.
Second, this patch fixes an issue when you have fission enabled, and a
setup such as:
A1 -> B1 -> A2
If you try to use IntersectionObserver from A2 with the implicit root,
we'd end up with:
* rootRect: A1's root scrollport rect (this is fine, because it's only
used to compute the root margin and bounds and so on, not
to compute geometry).
* rootFrame: A1's root scroll frame (this is _not_ fine, see below).
Then, we'd try to map rects from A2's target to A1's viewport, and we
can't really do that sensibly with the existing nsLayoutUtils functions,
because we're not accounting for all the OOP iframe transforms that may
be going on. This also triggers the assertion that this patch enables in
same-origin-grand-child-iframe.sub.html.
To fix it, for the A2 case, use the same code that we have for other OOP
iframes. The test tweaks fails with fission enabled without the patch
(because we don't account for the OOP iframe clip).
Differential Revision: https://phabricator.services.mozilla.com/D92089
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
In many cases with wpt, most of the tests in the file pass, but it is rather time consuming to annotate
.ini files case by case.
Differential Revision: https://phabricator.services.mozilla.com/D91977
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
And enable the assertion for the same-document case.
Without this patch, the assertion would fire in tests like
gfx/layers/apz/test/mochitest/test_group_zoom.html, where stuff like
MaybeHandleEventWithAccessibleCaret, which passes a non-root-frame down
here, and a target, which ends up violating the preconditions of
ClipToFrame, etc.
Enable the assertion for the same-document case, there are other
violations when fission is enabled in the cross-document case.
Differential Revision: https://phabricator.services.mozilla.com/D91966
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
Along with a dependent struct DirectDrawInfo.
This allows nsImageRenderer.h and CanvasRenderingContext2D.h to
avoid including nsLayoutUtils.h.
For nsImageRenderer.h in particular, a forward declaration is
not sufficient as nsImageRenderer stores SurfaceFromElementResult
by value.
A couple of method definitions elsewhere are moved out of line
to keep things compiling without including nsLayoutUtils.h in
additional headers.
Differential Revision: https://phabricator.services.mozilla.com/D91684
Right now the BoxToRect callback assumes that when it gets a
RECTS_ACCOUNT_FOR_TRANSFORMS flag, the "relative to" is an ancestor.
This holds for all the callers of GetAllInFlowRectsUnion except for [1],
which was introduced in bug 1581876, because they pass
GetContainingBlockForClientRect (that is, the root frame) as the root.
But that caller passes target, so IB split continuations or such would
get two siblings as the from/to frames, messing up the bounds.
An alternative would be to not pass the RECTS_ACCOUNT_FOR_TRANSFORMS
flag for that call (as it's computing a rect relative to self, but I
don't think that'd be quite correct in the presence of fragmentation
with transformed containers (if that's possible at all? would need to
think harder...)), but it seems like the API should just behave more
generally, or assert otherwise.
To that effect, this patch adds an assertion to TransformRectToAncestor
that would've caught this bug (though there are some pre-existing
violations, so we'll fix them in another bug).
[1]: https://searchfox.org/mozilla-central/rev/dfd9c0f72f9765bd4a187444e0c1e19e8834a506/dom/base/DOMIntersectionObserver.cpp#340-341
Differential Revision: https://phabricator.services.mozilla.com/D91883
Also rename it to IsXULDisplayStyle() because nsStyleDisplay often has
"Style"-suffix for related helpers.
(Note: IsXULDisplayType() is not used in GetAspectRatio() in the final
revision, but this part is still a good simplification.)
Differential Revision: https://phabricator.services.mozilla.com/D91228
For now, GetAspectRatio() is just an alias for GetIntrinicRatio(). In
Part 7, we're going to have GetAspectRatio() consider aspect-ratio
property so that each replaced elements only need to report their
intrinsic ratio via GetIntrinicRatio(). Non-replaced element can also
call GetAspectRatio() to get the ratio suitable to calculate layout
size.
As of this patch, all the replaced elements'
GetIntrinsicRatio() (including nsImageFrame::mIntrinsicRatio) consider
aspect-ratio properties (added in bug 1639963). This is wrong, because
it affects replaced element's content ratio. So we adapt only callers
[1] involving the computation of the frame's external sizes to retain
the behavior after Part 7.
This change shouldn't change behavior.
[1] Exceptions include 1) a caller in nsIFrame::ComputeSize() checking
the frame has no intrinsic ratio; 2) other frame classes implementing
nsIFrame::GetIntrinsicRatio() by calling their parent's
GetIntrinicRatio(). nsSubDocumentFrame::GetIntrinicRatio() is an
example.
Differential Revision: https://phabricator.services.mozilla.com/D91227
Apparently a bunch of Stringify(nsRect) sites were getting converted to
Stringify(nsRegion(nsRect)) due to the the nsRegion implicit constructor, so
this updates those too.
Depends on D91524
Differential Revision: https://phabricator.services.mozilla.com/D91525
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
nsContainerFrame.h was only using the enum nsLayoutUtils::IntrinsicISizeType,
which this patch moves to LayoutConstants.h instead.
Depends on D91505
Differential Revision: https://phabricator.services.mozilla.com/D91506
The only thing in nsIFrame.h that was using it was the implementation
of a templated method, which could be moved to nsIFrameInlines.h.
Depends on D91504
Differential Revision: https://phabricator.services.mozilla.com/D91505
This patch covers thw low-hanging fruit: headers that either don't use
nsLayoutUtils.h at all, or where only method implementations that can
easily be moved to the .cpp file use it.
Differential Revision: https://phabricator.services.mozilla.com/D91504
The two existing uses were inconsistent in whether the margins
were relative to the visual viewport or the layout viewport.
We could fix this, but it turns out both uses are readily
refactored to not need the field, so this patch removes the
field.
Differential Revision: https://phabricator.services.mozilla.com/D91479
This creates a marker that starts when an observer is added and ends when it is removed.
If there are multiple observers at the same time, their markers overlap.
The current profiler markers API only lets us insert the marker once we know
both the start and the end timestamp. This means that, if a profile is captured
in the middle of a refresh observer's observation period, there will not be a
marker for that observer in the profile. This can be improved once we have a way
to emit separate start and end markers and a way to associate the correct markers
with each other (bug 1661114).
Differential Revision: https://phabricator.services.mozilla.com/D91059
This was only being checked on OnDonePrinting() which isn't called in
the original docshell. Move it to the window because we don't need to
care about document viewers getting closed during print operations,
they're top level browsers that don't run script.
Differential Revision: https://phabricator.services.mozilla.com/D91416
Keyboard arrow key scrolls go through PresShell::ScrollLine/ScrollCharacter. When these look for a scroll frame they eventually end up at nsLayoutUtils::GetNearestScrollableFrameForDirection.
nsLayoutUtils::GetNearestScrollableFrameForDirection does two things wrong when determining if the scroll frame is scrollable by apz: it disallows overflow hidden scrolling, and it uses GetAvailableScrollingDirections which is based on the layout scroll range.
Using GetAvailableScrollingDirectionsForUserInputEvents takes into account both of these factors.
GetNearestScrollableFrameForDirection is used by:
-gfx/layers/apz/src/FocusTarget.cpp
-EventStateManager::DoContentCommandScrollEvent
-PageMove, ScrollPage, ScrollLine, ScrollCharacter, CompleteScroll of PresShell
All of these should want the more apz aware function.
Differential Revision: https://phabricator.services.mozilla.com/D90498
The current formulation is inconsistent. If you call it with ScrollableDirection::Either it goes into nsLayoutUtils::GetNearestScrollableFrame which will return the first scroll frame with a non-hidden overflow. If you call it with any other ScrollableDirection it calls nsLayoutUtils::GetNearestScrollableFrameForDirection which returns the first scrollframe it finds that has non-hidden overflow AND has at least one dev pixel of scroll range.
So remove that function and call nsLayoutUtils::GetNearestScrollableFrameForDirection directly. This is a slight change of behaviour but it seems desirable for all callers.
Differential Revision: https://phabricator.services.mozilla.com/D91236
The problems that it causes that are referred to in the patch is that we use the vvoffset and GetScrollRangeForUserInputEvents to compute the scrollbar cur, min, and max attributes. If we have a non-zero vvoffset when we are zooomed backed out, GetScrollRangeForUserInputEvents will be a zero range and so the cur attribute (non-zero) will be larger than the max attribute (0).
This then causes nsSliderFrame::AttributeChanged to call ScrollByWhole at
https://searchfox.org/mozilla-central/rev/30e70f2fe80c97bfbfcd975e68538cefd7f58b2a/layout/xul/nsSliderFrame.cpp#204
Which we definitely do not want.
Differential Revision: https://phabricator.services.mozilla.com/D90372
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
In SVG frame tree SVG{Inner,Outer}Frame is normally not scrollable but clips
descendants, thus nsLayoutUtils::GetNearestScrollableFrame is not able to find
the clip/scroll frame. So in this change, we introduce
GetNearestOverflowClipFrame which is a similar function to
GetNearestScrollableFrame but it also checks whether the frame is SVGInnerFrame
or SVGOuterFrame which is clipping the given nsIFrame during walking up the
frame tree.
In this change we also change the logic to get the clip/scroll frame and the scroll
id as follows;
1) Get the nearest overflow clip frame in the same document
2) Use the root frame if there is no clip frame
3) Then try to find the scroll id if the clip frame is asynchronously scrollable
so that it becomes clearer before. It's still messy though.
Differential Revision: https://phabricator.services.mozilla.com/D90647
The existing heuristics in GetClickableAncestor have evolved over time to be
quite specific to mouse/click events, because those are the ones that we have
enabled by default. The heuristics we want for touch events are different and
should generally be very conservative, because we almost never want to retarget
the raw touch events. This patch introduces a new GetTouchableAncestor
function that implements this new conservative heuristic function and uses it
for determining the retargeting destination for touch events.
Differential Revision: https://phabricator.services.mozilla.com/D91027
There's a few early-return conditions where we don't need to do this computation
at all. So this patch just moves the computation to after the early-returns. No
functional changes intended.
Differential Revision: https://phabricator.services.mozilla.com/D91025
Otherwise the only time it gets set is when the ZoomConstraintsClient specifically sets it in response to one of the things that can change it. But if the scroll frame gets reconstructed and one of those things don't happen it will be wrong.
This shows up with desktop zooming scrollbars because we check mZoomableByAPZ (or WantAsyncScroll()) before we use the apz scroll path in ScrollFrameHelper::ScrollBy().
Differential Revision: https://phabricator.services.mozilla.com/D90384
The displayport is aligned to screen pixels by an alignment number; there was
code to increase that alignment number for the WebRender codepath. This is
desirable because it causes the displayport to move less frequently, which
provides better performance characteristics with WebRender. However, the
way that was implemented, it was possible for the aligned displayport to not
completely enclose the unaligned displayport, which could then result in
perma-checkerboarding.
This patch removes that code and replaces it with a simpler approach to scale
up the existing alignment number by a factor based on the size of the scroller's
base rect (roughly how much of the scroller is visible to the user).
This does make the displayports larger, more so for scrollers with more visible
area. This has negative performance implications, so we mitigate that by also
scaling down the displayport margin multiplier by the same scaling factor. This
isn't perfect, but seems to work well enough in practice.
Differential Revision: https://phabricator.services.mozilla.com/D90503
This broke in bug 1636728 because we started setting the bit in the
cloned docshell rather than the original one.
Behavior in other browsers seems to be a bit all over the place, but for
now keeping our behavior during window.print() seems sane.
Differential Revision: https://phabricator.services.mozilla.com/D90456
This patch includes a couple of changes.
1) Notify contentful paint only during refresh driver ticks.
2) Not only the root document, sub document should also have their own
contentful paint entry.
3) Consider invisible text as contentful as well.
Differential Revision: https://phabricator.services.mozilla.com/D89498
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
We usually suppress background images in
nsCSSRendering::PaintStyleImageLayerWithSC, but that codepath isn't hit
by WebRender, so instead do it during display list building, the same
way we suppress background colors.
Differential Revision: https://phabricator.services.mozilla.com/D90278
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
This is sad, but seems like the least bad option to enable desktop zooming scrollbars reasonable soon.
Depends on D89409
Differential Revision: https://phabricator.services.mozilla.com/D90181
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
Doing rAF rAF flushApzRepaints is not enough to make sure that any potential scroll events are sent to content. The reason is that if the apz repaint request causes us to do scrolling on the main thread then the scrolling will be finished after flushApzRepaints, and the scroll event will be pending, but it's not sent until the next refresh driver tick. So we need to do at least one rAF after flushApzRepaints.
Differential Revision: https://phabricator.services.mozilla.com/D90035
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
Per spec we shouldn't behave differently depending on how we blocked the
image/object/etc.
This may have made sense in the past when ad blockers were implemented
via nsIContentPolicy, but I think nowadays it doesn't make sense, and
showing fallback is preferred.
There's a couple extra cleanups we can do after this lands, like
removing HTMLImageElement.imageBlockingStatus and simplifying a bit that
code. But I'll do that in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D89912
This adds a ScrollPositionUpdate class. Code in nsGfxScrollFrame creates
instances of these classes every time the scroll generation is incremented,
and saves them to an array. The array is sent in the scroll metadata to the
compositor as part of a paint transaction.
Currently this data is not used at all on the APZ side, and exists alongside
(independently of) the existing scroll fields, so this patch should not have
any functional effects.
Differential Revision: https://phabricator.services.mozilla.com/D88741
We treat it exactly the same as -moz-broken. The pseudo-class is not
exposed to content, so I don't think we have a reason to keep it around.
Differential Revision: https://phabricator.services.mozilla.com/D89904
In the next part, I'm going to use ComputeSizeFlags as the arguments in
some ReflowInput's methods. Because nsIFrame.h includes ReflowInput.h,
to solve the circular dependency, ComputeSizeFlags needs to be moved to
somewhere else.
Also, revise the document for ComputeSizeFlag. The rest of the patch is
just dropping `nsIFrame::` and adding `mozilla::` as needed.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89542
The test fixes all fell into the follow categories:
A) The test uses requestAnimationFrame to wait one frame and expects scrolling to be complete. With the desktop zooming scrollbars in order for the scrolling to show up on the main thread we need to send the scroll request to the compositor and then hear back from it via an apz repaint request (apz callback helper). Waiting on requestAnimationFrame will complete the first part, but not necessarily the second part. The fix is to wait for a scroll event.
B) Switching tests to wait for scroll events exposes another problem: the test can do things that cause a scroll in order to setup the test (and that may not be obvious that it causes a scroll) before actually proceeding to do the test and do something that causes a scroll and then checks for the scroll change of the second thing. Waiting for a requestAnimationFrame would include both those scrolls without desktop zooming scrollbars, but if we wait for a scroll event we will get the scroll event for the first thing which we are not interested in. So we need to make sure scroll events are cleared out before waiting for any scroll events. We do this by waiting two requestAnimationFrame's and waiting for apz to be flushed. We also use this when a test does something and it wants to test that scrolling is not performed.
The main thing that causes scrolling that may not be obvious: calling node.focus(). With stacks like:
from test_scroll_per_page.html
```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#02: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::layout::ScrollAnchorContainer::ApplyAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4742913]
#04: mozilla::PresShell::FlushPendingScrollAnchorAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4650069]
#05: mozilla::PresShell::ProcessReflowCommands(bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x465742b]
#06: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656af8]
#07: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#08: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#09: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#10: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#11: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#12: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#13: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#14: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```
from editor/libeditor/tests/test_bug549262.html
```
#01: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#02: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::PresShell::ScrollFrameRectIntoView(nsIFrame*, nsRect const&, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x46541bc]
#04: mozilla::PresShell::DoScrollContentIntoView() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4653776]
#05: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656b11]
#06: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#07: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#08: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#09: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#10: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#11: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#12: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#13: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```
C) Several tests use nsIDOMWindowUtils advanceTimeAndRefresh/restoreNormalRefresh and expect scrolling to be done after a call to advanceTimeAndRefresh. This is basically A), advanceTimeAndRefresh does a refresh driver tick but doesn't allow a repaint request to come back to the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D89403
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
We were adding the unwriteable to the default margin. I was going to
consider not painting the headers / footers if they overlapped with the
content box of the page, but turns out our default configuration
overlaps slightly at the bottom, so I just punted on that.
Users can remove the headers / footers quite easily anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D89794
Mostly mechanical change, with some extra work where non-literal names are provided.
Also, when this is the only profiler call in a file, `#include "GeckoProfiler.h"` can be changed to `#include "mozilla/ProfilerMarkers.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D89415
When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert
```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#01: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#02: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```
This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.
Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.
Differential Revision: https://phabricator.services.mozilla.com/D89409
This shouldn't generally happen, but seems it can under some circumstances and
even though I've fixed the error condition that triggers this a null-check here is harmless.
Differential Revision: https://phabricator.services.mozilla.com/D89453
sendKey uses our new relative scroll path that does the scroll by the apz. But we don't have any scroll event ordering expectations when apz is doing the scroll. We trade lossing those expectations for smoother apz scrolling.
So change the test to use a method that doesn't use our new relative apz scroll path and goes back to main thread scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D89402
Kartikaya Gupta
Masayuki Nakano
Razvan Maries
Kris Maglione
Agi Sferro
Emilio Cobos Álvarez
Sylvestre Ledru
Denis Palmeiro
Narcis Beleuzu
Botond Ballo
Daniel Holbert
Edgar Chen
Timothy Nikkel
Cameron McCormack
Frederic Wang
Gerald Squelart
Olli Pettay
Bogdan Tara
Jonathan Watt
Ting-Yu Lin
Butkovits Atila
Markus Stange
Florian Quèze
Miko Mynttinen
Csoregi Natalia
Peter Van der Beken
Mihai Alexandru Michis
Stephen A Pohl
Simon Giesecke
Hiroyuki Ikezoe
Bas Schouten
Jonathan Kew
Dorel Luca
Sean Feng
Andreas Farre
Barret Rennie
Noemi Erli
Nicklas Boman
Emilio Cobos Alvarez