Firefox should allow users to override scrollbar-width
Categories
(Core :: Widget: Cocoa, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: erwinm, Assigned: emilio)
Details
(Keywords: access)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
Visited www.tumblr.com/dashboard
Actual results:
Some sites use scrollbar-width: thin or scrollbar-width: none.
Since standard Mac scrollbars are already almost unusable, making them thin makes them completely unusable for clumsy users. I have other software to scroll, but if users don't buy special software, usable scrollbars can be important.
In any case, making them none will also make them completely unusable.
Expected results:
Scriollbars should be wide enough to use.
related: bug 1568539, which was closed as won'tfix for web-designer-end reasons.
possibly regressed by: bug 1484565, which implements thin on Macs.
Sorry, related: bug 1568939. clumsy of me...
Moving to: Core > Widget: Cocoa, if this is not the right component, please move it to a more appropriate one. Thanks!
Comment 3•3 years ago
|
||
I think a change here would benefit from input from our accessibility folks. Could a possible compromise be a pref that disables scrollbar-width: thin and scrollbar-width: none? Is this an issue on other platforms?
(In reply to MarjaE from comment #0)
related: bug 1568539, which was closed as won'tfix for web-designer-end reasons.
Did you mean to reference a different bug? I don't believe bug 1568539 is related to scrollbars.
Comment 4•3 years ago
|
||
I meant to leave this in the widget:cocoa component. I see that the "access" keyword was already set on the bug, so this should get picked up by accessibility triage.
Comment 5•3 years ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #3)
Did you mean to reference a different bug? I don't believe bug 1568539 is related to scrollbars.
Reporter meant bug 1568939 as you can see from comment 1.
Comment 6•3 years ago
•
|
||
(In reply to Gingerbread Man from comment #5)
(In reply to Stephen A Pohl [:spohl] from comment #3)
Did you mean to reference a different bug? I don't believe bug 1568539 is related to scrollbars.
Reporter meant bug 1568939 as you can see from comment 1.
Thanks, I missed that.
Comment 7•3 years ago
|
||
Based on this section of the scrollbar width spec, adding some notes:
With respect to scrollbar-width:thin
the spec says:
Note: User agents can use various strategies to ensure the usability of narrow scrollbars. For instance, in the case of overlay scrollbars, they can dynamically enlarge the scrollbar in response to a user attempting to interact with it. User agents on devices with touch screens can also adjust how they interpret finger taps to facilitate interacting with visually small touch targets.
It sounds like we should be exposing a preference here allowing users to override an author's chosen scrollbar width
Also, for scrollbar-width:none
the spec says:
Using this value can prevent mouse-only users from being able to scroll. Authors should ensure that mouse-only users can still reach hidden content, even if they have no scrollwheel.
Whatever preference we decide to expose for overriding scrollbar-width:thin
should also apply (or have an option to apply) to none
too. Despite the spec, I'm sure we'll run into pages in the wild where authors have failed to provide this ^ for users.
Comment 8•3 years ago
|
||
Marking [access-s2] on the basis that this can make some pages completely unscrollable for mouse-only users
Comment 9•3 years ago
|
||
Also, if we go the route of adding a preference/changing behaviour, I think this might need to live in another component -- not sure which though. Layout, since it handles scrollbar-width? ni'ing emilio for triage help/thoughts :)
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
(In reply to Morgan Reschenberg [:morgan] from comment #7)
Whatever preference we decide to expose for overriding
scrollbar-width:thin
should also apply (or have an option to apply) tonone
too. Despite the spec, I'm sure we'll run into pages in the wild where authors have failed to provide this ^ for users.
That's less of an issue because they would've failed to provide that for all users. That's a website bug.
Assignee | ||
Comment 11•3 years ago
|
||
Needs a reftest but it's friday night.
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
bugherder |
Updated•2 years ago
|
Description
•