Sidebar vertical tabs scrollbar doesn't always autohide
Categories
(Core :: Layout: Scrolling and Overflow, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | verified |
People
(Reporter: muffinresearch, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-sidebar])
Attachments
(6 files)
STR:
- With
sidebar.revampandsidebar.verticalTabsenabled in Nightly. - With enough tabs to be scrollable and move the mouse off of the sidebar and you will find it's possible to have the sidebar scrollbar remain visible.
- Seems to be a bit easier to reproduce with a longer bar for scrolling and scrolling to the bottom before switching to settings.
- Note this can be difficult to reproduce and take several attempts to get the issue.
What Happens
The scrollbar sometimes remains visible rather than disappearing.
What should happen
The scrollbar should autohide.
Platforms:
I can reproduce this in Nightly Mac, Windows and Linux. See screenshots.
- Windows 11: 131.0a1 (2024-08-20) (64-bit)
- Ubuntu 22.04: 130.0a1 (2024-08-03) (64-bit) - Deb package.
- Mac OS: 131.0a1 (2024-08-20) (64-bit)
| Reporter | ||
Comment 1•1 year ago
|
||
| Reporter | ||
Comment 2•1 year ago
|
||
| Reporter | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 3•1 year ago
|
||
Does this still reproduce? I have a vague memory of a similar issue being fixed elsewhere recently...
Comment 4•1 year ago
|
||
I might be thinking of bug 1915599. Not sure if that is relevant here.
Comment 5•1 year ago
•
|
||
I can still reproduce it on mac; If I scroll up and then down and hover over the scrollbar it seems to get stuck in the hover state (even after rebasing on changes from bug 1915599 and with my fix for bug 1913279).
Comment 6•1 year ago
|
||
This looks suspicious: https://searchfox.org/mozilla-central/rev/cc01f11adfacca9cd44a75fd140d2fdd8f9a48d4/browser/themes/shared/tabbrowser/tabs.css#835-836
Does removing this perhaps help with the behavior here?
Comment 7•1 year ago
|
||
Playing around with it in the devtools inspect it does seem like removing it does solve the issue, from what I can see. I had added that initially because there was a noticeable gap between the scrollbar and the edge of the container, but now with the changes to the styling its less perceptible.
Comment 8•1 year ago
|
||
Looks like bug 1916954 removed the negative margin.
| Reporter | ||
Comment 9•1 year ago
|
||
I can still repro with a build that includes the negative margin removal.
| Reporter | ||
Comment 10•1 year ago
|
||
Interesting side note: This isn't reproducible with reduce-motion enabled in OS accessibility settings (accessibility -> display) on OSX. Also the scrollbar seems a lot more snappy with animations off (which is perhaps to be expected) but still worth noting.
| Reporter | ||
Comment 11•1 year ago
|
||
Hi Emilio, I was wondering if you'd have any suggestions or thoughts on what could be the cause of this issue? As well as the STR see the note in Comment 10 that reduce motion seems to stop it being triggered.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 12•1 year ago
|
||
For the vertical tab bar, probably due to how it re-implements
scrolling1, 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.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 13•1 year ago
|
||
The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.
Comment 14•1 year ago
|
||
Comment 15•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
I am still able to reproduce the issue intermittently, on Firefox 132.0b5, using macOS 14.7, as described in Comment 5. The scrollbar remains visible even after moving the mouse around.
Also, I can reproduce it on Windows 11 with the same Firefox version if I release the click outside of the tab strip area, after scrolling up or down - please see the attached video - but the scrollbar hides as soon as I move the mouse again.
@emilio, should we reopen this? Thanks in advance!
| Assignee | ||
Comment 17•1 year ago
|
||
Can you open another bug? The root cause is very likely different.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #17)
Can you open another bug? The root cause is very likely different.
Yes, of course. Logged bug 1924079.
And regarding this issue, I am unable to reproduce it with Firefox 132.0b5 while following the steps from Comment 0, but I am still able to reproduce it on macOS 14.7 as mentioned in Comment 5. I will attach a video as well. Should we also track this separately?
@Emilio, regarding Comment 18, should we reopen this ticket as I am still able to reproduce the issue on Firefox 132, on macOS 14.7, as described in Comment 5? Thanks!
| Assignee | ||
Comment 21•1 year ago
|
||
The original bug was reproducible on Linux and Windows, and I can't repro it there, so no, separate bug please.
| Assignee | ||
Comment 22•1 year ago
|
||
(Please ni? me on the new bug, I think I might know what's going on, hover in macOS scrollbars is generally sticky but we should still clear the stickiness on mouseout...)
Thank you for the confirmation!
I am also unable to reproduce the issue on Firefox 132.0b8 using Windows 11 and Ubuntu 22.04 as described in Comment 0. Marking this verified as fixed.
Logged bug 1925564 for the macOS behavior.
Description
•