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
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 41f6f7691af60401f18f98a89f1878cfad2e74d3
extra : source : 3033401ef320414ef5f489c53526d015c38a89d7
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 : 44797fcf6585d5912f83baea90a8e554f39618b5
extra : histedit_source : c4354ba8aac99e0d083f40b515369db6a95f997d
This commit adds a barebones class called 'ScrollAnchorContainer' that will
contain most of the logic for scroll anchoring. It is owned as a member of
ScrollFrameHelper, and has the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D13267
--HG--
extra : rebase_source : 4d58b51aa6b893392d7c152d27750ebda059f784
extra : histedit_source : 9a2841931c47c4358e15d2fa6514ed347e3d0dad
This adds a notification from APZ to the scrollbar's slider frame to
inform it of APZ starting an async scrollbar drag. This is useful
because APZ can start a scrollbar drag and even change the scroll
position before the scrollbar frame even handles the mousedown event. In
such a case, the mousedown can land on where the scrollthumb *used to
be* before it was dragged away. This can result in scroll-to-click
behavior getting triggered and the scrollthumb glitching.
With this patch, the new notification follows the same path as the
request-repaint message, and so is guaranteed to arrive at the scrollbar
before any request-repaint messages. It sets some state that can be used
to correct the behaviour described above.
Differential Revision: https://phabricator.services.mozilla.com/D12364
--HG--
extra : moz-landing-system : lando
Currently, GetSplittableType() is called only in
nsCSSFrameConstructor::CreateContinuingFrame(). The splittable concrete frames
should inherit from nsSplittableFrame, and must explicitly create continuing
frame in CreateContinuingFrame(). Thus, no need to maintain GetSplittableType().
Differential Revision: https://phabricator.services.mozilla.com/D10798
--HG--
extra : moz-landing-system : lando
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
