Now that we've removed nsXULScrollFrame, ScrollFrameHelper can be
subsumed under nsHTMLScrollFrame.
I want to do this before making scrollbars non-XUL.
Renaming to mozilla::ScrollFrame is left for a follow-up bug.
Differential Revision: https://phabricator.services.mozilla.com/D173063
I was feeling back for adding the extra TimeStamp member and realized
that we don't really need mScrollFrame. Use the container_of hack to
avoid storing the extra pointer.
Depends on D166972
Differential Revision: https://phabricator.services.mozilla.com/D166973
This patch tweaks our scroll-anchoring-disabling heuristic in two interesting
ways:
* First, it introduces a time factor. What we want to detect is
back-and-forth caused by a bogus page. Those are usually very fast to catch,
so add a 500ms timeout to detect the adjustments.
If we experimentally find out it's too low we can raise it.
* Second, tweak the average distance to 2px rather than 3px. That makes it
much harder to hit for legit pages (while it should still catch the cases
we're interested in).
Factor the code into a helper struct since it getting a bit more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D166972
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
Scroll anchoring updates the scroll positions with ScrollOrigin::Relative, thus
it's properly merged into the in-progress animation.
Differential Revision: https://phabricator.services.mozilla.com/D156932
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
