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
Adjust is-where-parsing.html to work with both the new and old behavior,
and add a test for the new behavior.
Depends on D90049
Differential Revision: https://phabricator.services.mozilla.com/D90050
Also combine the border and padding arguments for
nsContainerFrame::ComputeSizeWithIntrinsicDimensions(), too. This method
is used as a helper to implement ComputeSize() for various replaced
elements. Its callers are all within nsIFrame's derived classes'
overridden methods, so I'm not bothering to convert them in a separate
patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D90064
Adjust is-where-parsing.html to work with both the new and old behavior,
and add a test for the new behavior.
Depends on D90049
Differential Revision: https://phabricator.services.mozilla.com/D90050
UpdateScrollbarPosition should have been using scroll range and not scrolled rect for a long time. It didn't matter because we only used the top left of the rect which matched until bug 1654933 made GetScrollRangeForUserInputEvents return a rect that wasn't located at 0,0.
Differential Revision: https://phabricator.services.mozilla.com/D90031
Add an extra pixel of fuzziness for this test - a recent unrelated
change to WR thread timing made this intermittent fail more often.
Differential Revision: https://phabricator.services.mozilla.com/D90053
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 is just moving code to make it reusable in APZ. As part of this, I replace
use of Preferences::* with the StaticPrefs::* API, because we can't use
Preferences:: in the GPU process and we'll want to be able to invoke this code
from there.
Differential Revision: https://phabricator.services.mozilla.com/D89665
The only place these fields are still read are for detecting if an APZ animation
is pending (not yet submitted in a transaction) and we can replace that code
with something slightly simpler. And then delete the unused fields.
Differential Revision: https://phabricator.services.mozilla.com/D88751
The previous patches caused the scroll-behavior-element WPT to fail, specificallly
the subtest that does a no-op instant scroll immediately following an APZ smooth
scroll, within the same transaction. In this subtest, the APZ smooth scroll
request gets added to mScrollUpdates but then the instant scroll is a no-op
(destination is same as current position) so we early return and don't add a
scroll update for it. This patch adds a bit of code to the early-exit path to
detect this scenario and let APZ know to cancel the animation. By itself this
causes a different test to fail, because we also hit this codepath when the
main thread internally does a no-op instant scroll to reclamp the scroll offset
after a reflow. That requires further refining the condition with a new scroll
origin used for the clamping call.
This ain't the prettiest thing but I'm hopeful that after untangling more of
the surrounding code in the future we can replace this with something more
elegant.
Differential Revision: https://phabricator.services.mozilla.com/D88745
This rewrites a big chunk of the NotifyLayersUpdated code (most of the code that
deals with incoming scroll requests from the main-thread) to instead iterate
through the list of ScrollPositionUpdates on the metadata and apply them in
order. A bunch of the ApplyXXXUpdateFrom functions on FrameMetrics have their
innards deduplicated and boil down to a single line, which is then inlined, so
those functions get removed entirely.
Note that this rewrite doesn't yet handle all the possible types of
ScrollPositionUpdate instances, just the ones that the old code handled. In the
future this support will be fleshed out with tests to exercise the relevant
codepaths.
There is also a change to nsGfxScrollFrame which slightly modifies the semantics
of mApzScrollPos to handle the case where multiple relative scrolls happen in a
single transaction. As the implementation now requires multiple relative
ScrollPositionUpdates rather than a single "unified" relative scroll in the
FrameMetrics, we need to update mApzScrollPos for each relative
ScrollPositionUpdate we generate.
Differential Revision: https://phabricator.services.mozilla.com/D88744
The existing ScrollUpdateInfo that is used to store a "paint-skipped scroll" for
empty transactions is very similar to the new ScrollPositionUpdate class, so
we can delete the former and use the latter instead.
The important part of this change is that when applying the pending info to
a FrameMetrics, we now also append the ScrollUpdateInfo to the mScrollUpdates
list on the ScrollMetadata. This aligns the code with the previous few patches,
where we duplicate the scroll information in both the regular FrameMetrics
fields and the ScrollMetadata::mScrollUpdates array.
Note that the existing code may have a defect when multiple paint-skip scrolls
occur in a single transaction; only the newest one is kept. In the case where
the last paint-skip is an absolute scroll, this is fine, but a relative scroll
may end up clobbering a previous absolute scroll. This patch explicitly detects
the scenario with multiple paint-skip scrolls and bails out to a full paint
transaction. As a followup it should be possible to relax this restriction by
storing an array of pending ScrollPositionUpdate instances.
Differential Revision: https://phabricator.services.mozilla.com/D88743
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
These tests only failed on android, probably because the visual viewport size is different so we get a different result from the scrollbar calculation.
These tests seem to have an inconsistent mix of overflow: hidden and scrollbar-width: none. The desktop zooming scrollbars sometimes create scrollbars for overflow hidden now, so overflow hidden isn't enough, we need scrollbar-width: none.
layout/reftests/transform/compound-1-fail.html is the only file modified here that doesn't have overflow hidden or scrollbar-width: none already. Looking at the test it does not seem to be wanting to be anti-ref because of scrollbars (the transformed item looks different), so this seems to be an improvement (ie we won't pass because only the scrollbar differed).
Differential Revision: https://phabricator.services.mozilla.com/D90008
This happens when nsColumnSetFrame reflows its last column in an
unconstrained available block-size.
The wpt test can trigger the bug in a debug build easily. In opt builds like
Nightly, if one wants to load the test manually, additional incremental reflow
(such as opening devtools) may be needed to trigger the bug.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D86672
This commit remove the following preferences, which have been
disabled since Firefox 70:
- mathml.nonzero_unitless_lengths.disabled
- mathml.legacy_number_syntax.disabled
These are edge syntaxes for MathML3 lengths that don't align well
with CSS and we haven't received any bug report about it since they
were disabled. Tests are updated to treat attributes using such
values as invalid.
update tests
Differential Revision: https://phabricator.services.mozilla.com/D89920
In previous part, we changed SizeComputationInput::InitOffsets to take a
ComputeSizeFlags parameter instead of ReflowInputFlags. Now there's no
reason to put ReflowInputFlags under SizeComputationInput.
Also rename it to `Flags` because it now lives in `ReflowInput`.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89544
Currently, to set ComputeSizeFlags, the caller uses an anonymous enum as
a parameter to ReflowInput constructor to set ReflowInputFlags fields,
and then ReflowInput creates a ComputeSizeFlags from the relevant
ReflowInputFlags fields in Init().
This patch simplifies this flags handover by adding ComputeSizeFlags
parameter to ReflowInput so that the caller can create the flags and
pass it to ReflowInput directly. The can also simplifies the process
needed to add a new ComputeSizeFlag.
We still need to store ComputeSizeFlags in ReflowInput since there's one
caller in `nsBlockFrame::ComputeFinalSize` wanting to checking
`ComputeSizeFlag::BClampMarginBoxMinSize`.
Note 1: ComputeSizeFlags is added only to the ReflowInput's constructor
that also takes parent ReflowInput. The other constructor's existing
callers don't need it.
Note 2: I don't bother adjust the value of DUMMY_PARENT_REFLOW_INPUT,
CALLER_WILL_INIT, and STATIC_POS_IS_CB_ORIGIN because they are going to
be converted into a enum class in a later patch.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89543
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
This patch does:
1. Rename the original ComputeSizeFlags to ComputeSizeFlag (dropping the
"s"), and make it an enum class.
2. Make ComputeSizeFlags an EnumSet.
3. Adapt the users to use EnumSet's APIs.
The `Default` enum value in ComputeSizeFlag is not needed. It equals to an
empty ComputeSizeFlags.
This change shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D89541
By mistake the specification used to say that, for items spanning
multiple tracks, the growth limits of the tracks with an intrinsic max
track sizing function should grow to accommodate the minimum
contribution of the item.
But this was a mistake, because an intrinsic max track sizing function
can only be min-content or max-content. So instead of distributing the
minimum contribution, it should be the min-content contribution.
The spec has been fixed and there is a CSSWG resolution in
https://github.com/w3c/csswg-drafts/issues/4790
This patch fixes the problem by reverting 2b923d48ea7e. The change is
likely web compatible, since it only affects a rare edge case with
'minmax()' where the min sizing function is 'auto' or a fixed value
smaller than the min-content contribution, the max sizing function is
'min-content', and an item whose minimum contribution is forced to be
smaller than the min-content contribution, and spans multiple tracks.
Differential Revision: https://phabricator.services.mozilla.com/D89145
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
Mihai Alexandru Michis
Timothy Nikkel
Emilio Cobos Álvarez
Ting-Yu Lin
longsonr
Bas Schouten
Magnus Melin
Sylvestre Ledru
Glenn Watson
Lee Salzman
Narcis Beleuzu
Delan Azabani
Noemi Erli
Kartikaya Gupta
Razvan Maries
Frederic Wang
Botond Ballo
Oriol Brufau