corysanin/tubestation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bug 1914154 - Fix how we deal with APZ scrollbar activity. r=hiro

Browse Source 
For the vertical tab bar, probably due to how it re-implements
scrolling[1], we get multiple eTransformBegin state changes, but a
single eTransformEnd.

That ends up with a permanently-positive activity counter, which leaves
the scrollbar visible.

There might be an underlying APZ bug here, not sure if mismatched events
are expected, but it seems other handlers deal with this mostly
correctly, and the fix on layout's end is rather trivial, too, so this
seems worth doing.

[1]: https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/toolkit/content/widgets/arrowscrollbox.js#640-718

Differential Revision: https://phabricator.services.mozilla.com/D222431
This commit is contained in:
Emilio Cobos Álvarez
2024-09-18 15:01:19 +00:00
parent bda2157d15
commit 8b9e0c00d4
3 changed files with 12 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
layout/generic/ScrollContainerFrame.cpp
View File

@@ -2296,12 +2296,18 @@ void ScrollContainerFrame::AsyncScrollCallback(ScrollContainerFrame* aInstance,
}
void ScrollContainerFrame::SetTransformingByAPZ(bool aTransforming) {
if (mTransformingByAPZ && !aTransforming) {
PostScrollEndEvent();
if (mTransformingByAPZ == aTransforming) {
return;
}
mTransformingByAPZ = aTransforming;
if (!mozilla::css::TextOverflow::HasClippedTextOverflow(this) ||
mozilla::css::TextOverflow::HasBlockEllipsis(mScrolledFrame)) {
if (aTransforming) {
ScrollbarActivityStarted();
} else {
ScrollbarActivityStopped();
PostScrollEndEvent();
}
if (!css::TextOverflow::HasClippedTextOverflow(this) ||
css::TextOverflow::HasBlockEllipsis(mScrolledFrame)) {
// If the block has some overflow marker stuff we should kick off a paint
// because we have special behaviour for it when APZ scrolling is active.
SchedulePaint();