Unclear whether the visual viewport code path is the right thing to do at all.
Differential Revision: https://phabricator.services.mozilla.com/D47791
--HG--
extra : moz-landing-system : lando
See https://github.com/w3c/csswg-drafts/issues/4239
This fixes what is in my opinion one of the biggest issues of scroll anchoring
as specified / currently implemented.
It's trivial to flush layout on a scroll handler and create scroll adjustments,
which in turn would trigger other scroll events to be fired. This situation,
which is what has happened in most of the scroll anchoring regressions I've
fixed, at best gets pages to get stuck in an infinite CPU loop. At worst, it
causes scrolling to be unusable because the page keeps reacting to scroll
events.
An alternative, slightly more elegant but not clear to me if 100% implementable
approach would be bug 1529702.
This should enormously reduce the need for scroll anchoring suppression
triggers[1], I'd think, which in turn would allow me to investigate removing
some of that complexity.
https://drafts.csswg.org/css-scroll-anchoring/#suppression-triggers
The setup to set / unset the boolean is a bit awkward but I couldn't come up
with anything better.
Differential Revision: https://phabricator.services.mozilla.com/D43233
--HG--
extra : moz-landing-system : lando
In the previous commit, we expanded layout viewport height but during reflow
the expanded layout viewport size hasn't reflected in
ScrollReflowInput::mContentsOverflowAreas.ScrollableOverflow(). We explicitly
need to use the expanded height to tell whether we need vertical vertical
scrollbars or not.
Note that the expanded layout viewport height should NOT be used for non-overlay
scrollbars cases since, for example, if the content width is specified by
`width: 100%`, the non-overlay vertical scrollbar narrows down the content's
used width a little bit because of the vertical scrollbar width, which in turn
the minimum scale gets bigger because the content's width became bit narrower,
thus the layout viewport size calculated with the minimum scale gets smaller,
then it results the vertical scrollbar no longer needs to be rendered, thus
the minimum scale gets back to the original value, then the vertical scroll
needs to be rendered again, thus this sequence of processes happens repreatedly.
Differential Revision: https://phabricator.services.mozilla.com/D40772
--HG--
extra : moz-landing-system : lando
Converts layout.framevisibility.amountscrollbeforeupdatevertical and layout.framevisibility.amountscrollbeforeupdatehorizontal to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D40718
--HG--
extra : moz-landing-system : lando
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
Since scroll position restoration is absolute, and we'll lose it as soon as we
apply any adjustment or do any other sort of scrolling.
Differential Revision: https://phabricator.services.mozilla.com/D37941
--HG--
extra : moz-landing-system : lando
The function will also be used for `scroll-behavior` property in a later patch
in this commit series, so it needs a more reasonable name.
Differential Revision: https://phabricator.services.mozilla.com/D35738
--HG--
extra : moz-landing-system : lando
This is pretty much the same as ScrollStyles::IsSmoothScroll right now,
but in the next commit, we will no longer propagate scroll-behavior on <body> to
the root element so that nsIScrollableFrame::IsSmoothScroll will be changed
to reflect it.
Differential Revision: https://phabricator.services.mozilla.com/D35737
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
Now scroll-snap-type property on body element doesn't affect scroll position
so that scrollTo-scrollBy-snaps.html is needed to be modified to specify
scroll-snap-type on html.
Differential Revision: https://phabricator.services.mozilla.com/D27987
--HG--
extra : moz-landing-system : lando
The one is for the scroll snap module v1 implementation, the other is for the
old scroll snap implementation. Now both functions have the same pieces of
code to get scroll-snap-type values, but for v1 implemention in the next commit
we will use GetFrameForScrollSnap() to get the value instead.
Differential Revision: https://phabricator.services.mozilla.com/D27986
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
--HG--
extra : moz-landing-system : lando
In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
As for scrolling on the compositor we don't cull out them since we don't know
the final snapport rect at the time when we send the information about
snapping to the compositor. And we will handle it for APZ in bug 1531589.
https://drafts.csswg.org/css-scroll-snap-1/#snap-scope
Depends on D21632
Differential Revision: https://phabricator.services.mozilla.com/D21633
--HG--
extra : moz-landing-system : lando
From the spec [1];
Using the scroll-snap-type property on the relevant scroll container, the
author can request a particular bias for the scrollport to land on a snap
position after scrolling operations (including programmatic scrolls such
as the scrollTo() method).
The target here are functions exposed in web contents other than
Element.scrollIntoView which will be changed in the next commit.
[1] https://drafts.csswg.org/css-scroll-snap-1/#overview
Depends on D21624
Differential Revision: https://phabricator.services.mozilla.com/D21625
--HG--
extra : moz-landing-system : lando
elementFromPoint-002.html, elementFromPoint-003.html and dialog-showModal.html
use document.elementFromPoint with a given point which is calculated from the
value returned by getBoundingClientRect() for a 100% width element. Before
this change, the given point is outside of view because there is no viewport
meta tag in the documents so that elementFromPoint fails. After this change, the
documents fit to the visual viewport so that elementFromPoint works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D16155
--HG--
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
This patch renames nsIPresShell::SetPendingVisualScrollUpdate() to
ScrollToVisual(), and adds an instant vs. smooth option.
SetPendingVisualScrollUpdate() still exists, as a helper for the instant case.
Differential Revision: https://phabricator.services.mozilla.com/D24553
--HG--
extra : moz-landing-system : lando
This was introduced in bug 726817 for B2G stuff and there is no call site of
SetClampScrollPosition now and the only one entry point to call the function
was nsIFrameLoader.clampScrollPosition which was removed in
https://hg.mozilla.org/mozilla-central/rev/cd9aace7bb96 .
ScrollFrameHelper::ShouldClampScrollPosition() had always returned true in both
cases of root and non-root scrollable frames. (In the case of non-root
scrollable, nsFrameLoader.mClampScrollPosition is initially set to true and
nobody changes the value)
Differential Revision: https://phabricator.services.mozilla.com/D22026
--HG--
extra : moz-landing-system : lando
This maintains the important invariant that layers that carry scroll metadata
for the RCD-RSF are inside the async zoom container.
Differential Revision: https://phabricator.services.mozilla.com/D22049
--HG--
extra : moz-landing-system : lando
This is what Chrome does.
documentElement-clientWidth-on-minimum-scale-size.tentative.html was the test
case for this but unfortunately it was disabled in bug 1515043. And it seems
that the test case failed on Android in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D19461
--HG--
extra : moz-landing-system : lando
Before this patch, we made scrollable frames derive their baseline from their
margin-box, because that's what the spec requires for scrollable inline-block
boxes. However, the spec now singles out inline-block as a special case, and
other sorts of scrollable inline-level containers are supposed to derive their
baseline from the scrolled content. So, this patch makes us do that, with an
exception for scrollable inline-block boxes.
For more info about the block-inside special case, see the end of the "block
containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export
(Though that spec text may be a bit too specific, per my spec issue at
https://github.com/w3c/csswg-drafts/issues/3611 -- that's why this patch checks
for block-inside rather than inline-block.)
Differential Revision: https://phabricator.services.mozilla.com/D18481
--HG--
extra : moz-landing-system : lando
Without the check that I'm adding in this patch, we'd violate the
"parallel writing mode" expectation of some baseline accessors
that we use in the now-guarded code. And we'd produce bogus layout
as a result.
The added assertions are just for good measure. The included testcase
causes us to fail both assertions, in a build that's missing the fix.
Differential Revision: https://phabricator.services.mozilla.com/D18715
--HG--
extra : moz-landing-system : lando
This was lost in the change to only use the visual viewport if both the
size and offset were set.
Differential Revision: https://phabricator.services.mozilla.com/D17752
--HG--
extra : moz-landing-system : lando
This commit implements anchor offset adjustment. When the position of a frame
that is an anchor is changed during reflow, we notify the anchor container. The
anchor container will then post a reflow callback.
Then when reflow is completed, the anchor container will perform a scroll to
keep the anchor node in the same relative position.
Differential Revision: https://phabricator.services.mozilla.com/D13270
--HG--
extra : rebase_source : 9d40a5d5b73777d0da3799f162eeb85bb8e6d8f0
extra : source : d9052f7b34d9857863b66d64797f8b0b82504bec
