2033271 - Visual and interactional offset issue in vertical tabs ui

Status: RESOLVED FIXED

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[npt1237]

Attachment: 스크린샷 2026-04-18 195941.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

Rapidly scrolling up or down in vertical tabs often creates an unintended blank space (margin) at the top or bottom of the tab list.

The exact trigger is inconsistent. While it happens most often during fast scrolling, it sometimes occurs during slow scrolls as well. The frequency is unpredictable—sometimes occurring every time, and other times once in five attempts.

Actual results:

When this gap appears, the mouse cursor's focus becomes misaligned with the actual tab selection point by the height of that gap.

Scrolling back toward the gap usually forces it to disappear, which also restores the correct alignment between the cursor and the selection point.

Expected results:

The gap should not be appeared.

Comment 1

[npt1237]

Attachment: 스크린샷 2026-04-18 200025.png

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[:Gijs (he/him)]

This smells like a layout issue, not a frontend issue. Frontend code is not manipulating space above/below the actual scrollable elements unless dragging tabs, and the cursor being misaligned with where interaction happens I think would not be possible to achieve from frontend code alone (at least, not without trying to do it deliberatey, which we're obviously not).

Your screenshots show pinned tabs. Does this only reproduce in the situation where you have pinned tabs?

How are you scrolling - with a mouse scroll wheel, by dragging scrollbars, clicking in the scrollbar gutter, using the keyboard, or some other way? Can you describe what you do differently between what you call "fast scrolling" and "slow scrolling"?

Comment 4

[npt1237]

Pinning or grouping tabs did not affect whether this issue occurred.

From what I observed, this issue only happens when scrolling with a touchpad. It does not occur when using the mouse wheel, dragging the scrollbar, or using keyboard shortcuts.

As for the difference between fast and slow scrolling: fast scrolling means moving your finger quickly on the touchpad so that the tab strip scrolls fully to the opposite direction in a short time. Slow scrolling means letting the built-in scrolling acceleration carry the movement to the opposite end after initiating the scroll on the touchpad.

If I keep my finger on the touchpad and continue the input until reaching the opposite end, no blank space appears at the edge.

Also, the more tabs are open, the longer the scrollable area, the wider the blank space becomes, and the more frequently it occurs.

Comment 5

[npt1237]

*Slow scrolling means letting the scrolling acceleration itself carry the movement to the opposite end.

Comment 6

[npt1237]

From my intuition, it seems that the inertial scrolling input from the touchpad is not being handled properly by the sidebar layout. When I scroll while keeping my finger on the touchpad, it appears that the scroll position is consistently constrained by the upper and lower bounds. However, this inertial “gliding” input does not seem to be treated as part of that same input stream.

Comment 7

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Hey npt1237, would you mind trying to set "apz.overscroll.enabled" to false, then see if this bug still persists?

I am guessing the gap is generated due to overscrolling , but now I tried to see it locally, but I don't see any overscrolling in the tab scroll container for some reasons.

Comment 9

[npt1237]

Attachment: 2026-05-05 12-35-45(2).mp4

Comment 10

[npt1237]

It occurs regardless of "appz.overscroll.enabled".

Comment 11

[Hiroyuki Ikezoe (:hiro)]

npt1237, would you mind trying this build ? (you can directly download from this link) I hope this build fixes this issue. Thanks!

Comment 12

[npt1237]

Attachment: 2026-05-06 09-32-34(2).mp4

Comment 13

[npt1237]

I think the problem is solved.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Thanks.

Now I am ~90% sure this is a regression caused by bug 1871760. Since bug 1871760, we haven't clamped the visual scroll offset updated in ApplyRelativeScrollUpdateFrom because basically it has been clamped on the main-thread. But if there is a discrepancty between APZ and the main-thread, it will result out-of-bounds scroll offsets.

A patch is coming.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 2033271 - Clamp APZ visual scroll offset after applying relative ScrollPositionUpdate. r?botond

When APZ is mid-animation and the main thread fires an instant scrollBy that
overshoots the top or left boundary, ApplyRelativeScrollUpdateFrom can produce
a negative visual scroll offset. Setting needToReclampScroll after the relative
update triggers the existing post-loop clamping on both Metrics() and all
sampled states, preventing the negative offset. As a side effect the bottom and
right boundaries are also clamped consistently.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

And I guess the scroll container stuck issue on youtube (bug 1931090) is also the same symptom here.

Comment 17

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1871760

Comment 18

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1871760

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3c5e5ae6e010
https://hg.mozilla.org/integration/autoland/rev/2809c4bede1f
Clamp APZ visual scroll offset after applying relative ScrollPositionUpdate. r=botond

Comment 20

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/2809c4bede1f

Comment 21

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox152 to wontfix.

For more information, please visit BugBot documentation.