See link in the comment. We were checking both offsets, but blink only
checks one.
In this case, the page has a table with `overflow-x: auto` and
`overflow-y: hidden`. They implement a custom virtual scrolling on the
vertical axis, and scroll-anchoring interacts poorly with it.
Adapt zero-scroll-offset.html to test for this.
Differential Revision: https://phabricator.services.mozilla.com/D217201
The motivation of this patch is that we've now switched all the callers from
`nsIScrollableFrame` to `ScrollContainerFrame`, and it is better to audit the
access control of `ScrollContainerFrame`'s interface, and I notice almost all
the member variables are public!
This patch shuffle the interface so that there are only one public, protected,
and private section, and all the member variables are moved to the private
section.
`AutoMinimumScaleSizeChangeDetector` and `RemoveDisplayPortCallback` need to
access member variables, so by declaring them under `ScrollContainerFrame`, they
have the privilege to do so.
Ideally, the caller only need to access what are already in
`nsIScrollableFrame`, so currently we might expose more methods than necessary.
We can audit that in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D211499
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
The motivation of this patch is that we've now switched all the callers from
`nsIScrollableFrame` to `ScrollContainerFrame`, and it is better to audit the
access control of `ScrollContainerFrame`'s interface, and I notice almost all
the member variables are public!
This patch shuffle the interface so that there are only one public, protected,
and private section, and all the member variables are moved to the private
section.
`AutoMinimumScaleSizeChangeDetector` and `RemoveDisplayPortCallback` need to
access member variables, so by declaring them under `ScrollContainerFrame`, they
have the privilege to do so.
Ideally, the caller only need to access what are already in
`nsIScrollableFrame`, so currently we might expose more methods than necessary.
We can audit that in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D211499
Convert `nsIScrollableFrame` to `ScrollContainerFrame` for all the APIs in
nsLayoutUtils, and then adapt other callers until everything compiles.
In `nsLayoutUtils::CalculateBasicFrameMetrics()`'s documentation,
s/ComputeFrameMetrics/ComputeScrollMetadata/ because the method was renamed in
https://hg.mozilla.org/mozilla-central/rev/cb2023f50288
Differential Revision: https://phabricator.services.mozilla.com/D211493
Also, rewrite GetInlineDir() and GetBlockDir() to remove bit operations for
computing the InlineDir and BlockDir enum variants.
Differential Revision: https://phabricator.services.mozilla.com/D208176
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
With this pref we can avoid bug 1561450 without disabling any scroll adjustments
in scroll event handlers because in the specific case of the bug the scroll
adjustment in question is zero length such as
```
element.style.display = "block";
element.offsetTop // flush layout
element.style.display = "none";
```
so it can be caught by our existing consecutive adjustment heuristic. Thus with
the default layout.css.scroll-anchoring.max-consecutive-adjustments value, as of
now it's 10, the case of bug 1561450 will stop firing scroll events after
5 (= 10/2) additional scroll event observations.
Differential Revision: https://phabricator.services.mozilla.com/D178898
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
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
Emilio Cobos Álvarez