[Nova] Scrollbars get clipped by rounded corners in the browser chrome
Categories
(Core :: Widget, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: sthompson, Assigned: mhynson)
References
(Blocks 4 open bugs)
Details
(Whiteboard: [fidefe-nova])
Attachments
(2 files, 1 obsolete file)
The Nova redesign applies platform-specific border radius on major chrome elements (main content area, panels, sidebar, toolbars, etc.). Scrollbars render near the edges of those chrome elements, and in some configurations, the scroll "thumb" gets clipped when scrolling to the start or end of the scrollbar.
Windows
Not really affected. We're currently using a low 4px border-radius on chrome elements (8px was planned for Win11 but not yet implemented, see bug 2050511), and Windows scrollbars render with scrollbar arrows at the end. The scrollbar arrows don't get clipped themselves, and their presence prevents the scrollbar thumb from being clipped.
Linux
Somewhat affected. We default to 10px border-radius, but we pull values from the GTK theme header bar (e.g. 12px on Ubuntu Adwaita). Overlay scrollbars are drawn very thin and close to the edge of the scroll frame, which increases the risk of clipping, although hovered overlay scrollbars get pushed out from the edges. I haven't tested with non-native Linux rendering.
macOS
Tahoe and later is most affected. We use 16px border-radius and render with no scroll arrows. Every configuration of scrollbar clips.
Before Tahoe, we use 10px border-radius. This shows issues as well, but less severe.
Updated•2 months ago
|
| Reporter | ||
Comment 1•2 months ago
|
||
macOS Tahoe and later native apps usually only draw the scroll track in the non-rounded area of the window, e.g. if the window is rounded by 16px then the vertical scrollbar starts at y = 16px instead of 0px. Apple doesn't appear to have updated all of their apps or all of their scrolling configurations, so there are some places where it doesn't look great even in core things like System Settings.
:juliana and I discussed trying this same approach in order to mitigate this problem on macOS.
I wrote up a WIP patch at https://phabricator.services.mozilla.com/D301151 that implements this approach at the layout level. Emilio preferred to see an implementation only at the paint level, so I wrote up a second WIP patch at https://phabricator.services.mozilla.com/D312476. This suffered from issues of having a different scroll rect at the layout vs. paint levels, with the result being that a lot of mouse interactions with the scrollbar were off.
In both cases, the implementation is generally trying to calculate whether a scrollbar is going to intersect the rounded corner of a clipping ancestor. This is theoretically more dynamic, but also potentially more prone to edge cases. Emilio proposed a different approach by introducing a Mozilla-only CSS rule that the ScrollbarDrawing code can use in order to draw a shorter scroll thumb in a shorter scroll track.
For example, in the List All Tabs menu tabs list, the scrollable area when there are a lot of tabs usually isn't clipped on top (since there are fixed menu elements above it) and rounded corners on the bottom (since the scrollable area touches the bottom of the panel and the panel has rounded corners all around). Setting something like -moz-scrollbar-inset: 0 0 var(--chrome-block-radius) var(--chrome-block-radius) on that specific scroll frame would give us opt-in control for this behavior. It would also allow overriding the CSS rule to -moz-scrollbar-inset: 0 in the scenario where there is a sticky "View All Tabs" menu element after the scrollable tab list. The vertical tab strip in the sidebar is another place where rounded rect clipping is conditional on different states, e.g. whether there are pinned tabs.
There were some outstanding topics for learning/discussion:
- how/whether to let the CSS rule be inherited
- how to apply this specifically to the main content area's scroll frame
And generally, I think the idea with this approach is that we could do a best effort on specific surfaces.
Updated•2 months ago
|
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 2•2 months ago
|
||
- Adds a chrome-only, non-inherited CSS property
-moz-scrollbar-inset(top/right/bottom/left, like
inset) to allows specific chrome scroll frames to opt in to a shorter scrollbar to clear rounded corners. - Declare the shorthand plus four
Lengthlonghands (four_sides), gated to chrome/UA sheets - Regenerate use_counter_metrics.yaml and cover the property in property_database.js.
- ScrollbarDrawingCocoa: deflate the painted track and scroll-corner
rects by the inset, clamp the thumb into the inset band - POC to apply property to vertical tabs
| Reporter | ||
Comment 3•2 months ago
|
||
Putting a rough estimate of 5 points to help with prioritization
| Assignee | ||
Comment 4•2 months ago
|
||
- Forwards the content-area conrner raidus from
<browser>into the content document via the BrowsingContext field - Exposes the
env(-moz-content-scrollbar-inset)to content CSS
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Updated•1 month ago
|
Comment 7•1 month ago
|
||
Reverted this because it was causing build bustages.
- Revert link
- Push with failures
- Failure Log
- Failure line: gmake[4]: *** [/builds/worker/checkouts/gecko/config/makefiles/rust.mk:581: force-cargo-test-run] Error 101
Pleaso also check this one.
Comment 10•1 month ago
|
||
| bugherder | ||
Updated•24 days ago
|
Description
•