There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
This patch is a fairly mechanical conversion. The old `nullptr` gets converted
to ScrollOrigin::NotSpecified, and all the other possible values get corresponding
values in the new ScrollOrigin enum. A few switch statements are introduced to
clean up big if statements, but other than that, additional cleanups will happen
in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D78438
This change is for consistency with other similar logging, and to avoid getting
unrelated lines of logging concatenated together.
Calling this "DONTBUILD" because this is just a small tweak to an (opt-in)
debug logging string which probably doesn't get printed on TreeHerder, so
there's virtually no chance this could have an impact on any TreeHerder jobs.
Differential Revision: https://phabricator.services.mozilla.com/D76061
The test-case is position-change-heuristic.html but with body and #space
having overflow: hidden, which makes it fail on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D75825
This patch is generated by using my editor's rename functionality.
In the next patch, `nsIFrame::` prefix is going to be removed manually
from all the ChildLists() calls.
Differential Revision: https://phabricator.services.mozilla.com/D75893
We can modify the scroll position without invalidating the anchor (that's kind
of the point, actually).
So it's possible (and ok) to end up with a frame which is already maintaining
an anchor but for which CanMaintainAnchor now returns false.
So if you have a scrollframe with a non-zero scroll position and select an
anchor for that scrollframe, and then try to select an anchor for an ancestor,
you don't want to dig into there.
Differential Revision: https://phabricator.services.mozilla.com/D71103
--HG--
extra : moz-landing-system : lando
As long as the nested scrollframe doesn't maintain an anchor itself.
This is important for pages which use overflow: hidden to contain large
parts of their scrollable content, see bug 1629237 for an example.
When calling InvalidateAnchor(), we may invalidate an ancestor anchor
itself, if we're not maintaining an anchor and our scrolled frame is
part of the anchor chain. This is important to maintain our state
properly.
I was going to add some assertion to this effect but it can fail when
fragmenting inlines already, so for now I've commented it out and filed
bug 1629280 for that. It's not great, but it cannot lead to a security
issue so we probably can fix it with time.
Differential Revision: https://phabricator.services.mozilla.com/D70609
--HG--
extra : moz-landing-system : lando
Same case as the other smooth-scrolling thingies, scroll anchoring is less
prioritary (and is disturbing) in that case.
Also fix the logging code (`WritingMode::DebugString` is no longer a thing).
Differential Revision: https://phabricator.services.mozilla.com/D62050
--HG--
extra : moz-landing-system : lando
The idea of these are not to penalize legit uses of scroll anchoring, and
catching pathological cases fast.
The current algorithm I thought of is just whether the average of all the
consecutive scroll anchoring adjustments is less than a given threshold.
If the average adjustment is close to zero and the user is not scrolling, it
means that we're not making much progress.
It is important that zero adjustments don't get counted, since those are common
during window resizes and don't have side-effects anyway.
Exact number may need tuning, let me know if you want it
nightly-and-early-beta-only for now or something.
Depends on D51038
Differential Revision: https://phabricator.services.mozilla.com/D51024
--HG--
extra : moz-landing-system : lando
Otherwise we may keep the scroll anchor around and we may try to anchor to it
later even though we should've really suppressed it completely.
Maybe we should just call InvalidateAnchor() unconditionally from that code
path, even if there are no suppressions pending...
Differential Revision: https://phabricator.services.mozilla.com/D48456
--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
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--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
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
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--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
When visiting a text frame with many continuations, traversing ancestors to compute the
transform to the ancestor scroll frame can become very hot. This commit changes the
algorithm to translate all the text continuations to an ancestor that can then be
transformed just once.
Differential Revision: https://phabricator.services.mozilla.com/D17730
--HG--
extra : moz-landing-system : lando
A continuation text frame's rect will be considered when visiting the primary
frame via 'FindScrollAnchoringBoundingRect', so we have no reason to compute
the same rect again if for some reason we have excluded the primary text frame.
Differential Revision: https://phabricator.services.mozilla.com/D17729
--HG--
extra : moz-landing-system : lando
The important piece is just that we don't queue a selection for later. This code runs
for each scroll, so we'd be wasting a lot of effort to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17050
--HG--
extra : moz-landing-system : lando
This commit changes ScrollAnchorContainer to store the offset between the scroll anchoring
bounding rect start edge and the scroll-port start edge in the block axis of the scroll frame.
The logic to clamp the negative portions of scroll anchor bounding rect is also amended
to only clamp the portion that is beyond the border start edge in the block axis of the
scroll frame.
Differential Revision: https://phabricator.services.mozilla.com/D16757
--HG--
extra : rebase_source : 43b5bc4ece7f90cb38e3a7186a764d9cddac90f9
extra : source : f26d953d76fcfb02a5fa46cb62e389f852592fe9
