scrollbar-width:thin prevents overflow-y:auto from working after page load

VERIFIED FIXED in Firefox 65



4 months ago
3 months ago


(Reporter: alexandre, Assigned: xidorn)



Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 wontfix, firefox65 verified, firefox66 verified)



(2 attachments)



4 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Use a CSS with overflow-y:auto and scrollbar-width:thin on an element, which height changes after the page is loaded.

Live example:

Actual results:

No scrollbar appears, despite overflow-y:auto (it works when removing scrollbar-width:thin). Tested on Firefox Nightly.

Expected results:

A scrollbar should appear (just like with scrollbar-width:auto).
Hmm, wfm on Linux. Xidorn, can you take a look on Windows?
Flags: needinfo?(xidorn+moz)

Comment 2

4 months ago
Ah indeed, works with Firefox Nightly on Ubuntu 18.04 LTS. So either Windows-specific, or at least window-manager specific.

Comment 3

4 months ago
If someone else lands on this bug, here is my workaround:

if (div &&	//Workaround for Gecko bug in Firefox 64-65(+?):
    div.scrollHeight > div.clientHeight &&	//if scrollbar needed
    div.scrollWidth >= div.offsetWidth) {	//but no scrollbar['overflow-y'] = 'scroll';	//then force scrollbar refresh
	setTimeout(function () {['overflow-y'] = ''; }, 0);	//and back to default

Comment 4

4 months ago
I can reproduce this on Windows but not macOS... I'll try to investigate, so keep ni? for now. (but I don't have Windows development environment at the moment, unfortunately...)
Ever confirmed: true


4 months ago
Blocks: 1460109

Comment 5

4 months ago
After tracking down a bit, I now know the reason of this bug.

The root cause is probably that nsBoxFrame caches its pref size, and never updates it.

When we reflow scrolled frame, we read the pref size of frame of <scrollbar> element, which is an nsBoxFrame. When the scrollbar shows initially, the pref size of <scrollbar> in nsBoxFrame is correct, and thus it can show and hide without problem.

However, when the scrollbar doesn't show initially, it gets attribute `disabled="true"` which in turn sets `collapsed="true"` on its grandchild <thumb> element, and that makes the scrollbar having zero pref size, because the only element provides the size is collapsed (with `visibility: collapse` from , and such pref size is cached and never recalculated again. Consequently we would never see the scrollbar.

The reason that it doesn't affect "scrollbar-width: auto" is because non-thin scrollbar on Windows still has scrollbar buttons, which can provide the width.

It's still not clear to me, though, what is the best way to fix it. nsBoxFrame's pref size caching seems to be a long-existing behavior, which might be risky to "fix".

The behavior which sets `collapsed` on <thumb> when <scrollbar> is disabled was added in bug 271974, which is titled "Scrollbars should look disabled when there's nowhere to scroll", so my guess is that the intention is just to hide the thumb in that case, so maybe a safer solution would be to set something like `visibility: hidden` or so on the <thumb>...

Comment 6

4 months ago
Posted file testcase


4 months ago
Assignee: nobody → xidorn+moz
Flags: needinfo?(xidorn+moz)

Comment 7

4 months ago
Collapsing thumb causes frame of scrollbar to cache an incorrect pref
size, which makes it not able to appear in certain cases.

This patch changes it to use "visibility: hidden" instead so that the
thumb is hidden but still contributes to the width of scrollbar.

An alternative would be also change the code in nsScrollbarFrame to set
something other than collapsed attribute instead, but I'm not sure
whether doing that is any better than just adding a rule. We need the
rule anyway regardless of what we set on the element.

Comment 9

4 months ago
As suggested... notes from bug 1514875

On Firefox 66.0a1 (2018-12-17) (64-bit) I was testing scrollbar-width but the result is inconsistent. (not tested on FF64-65) 

- Testing on "options_ui" 

  "options_ui": {
    "page": "content/options.html",
    "open_in_tab": true,
    "browser_style": true

Setting to 'scrollbar-width: thin;' on reload the scrollbar disappears completely. (the scrolling action works)
Strange thing is that as soon Developer Tools (F12) is launched, the thin scrollbar appears and stays on once the Developer Tools is closed.

- Testing on a normal web page:
Setting to 'scrollbar-width: thin;' works fine and as expected.
Priority: -- → P2

Comment 10

4 months ago

Neil, could you have a look at the patch here? It is a tiny one, and should be reasonable easy to review. If you are not comfortable with reviewing that kind of reftest, I can request other people to review that part. You can see comment 5 for the explanation of the cause of this issue. Thanks!

Flags: needinfo?(enndeakin)


3 months ago
Flags: needinfo?(enndeakin)

Comment 11

3 months ago
Pushed by
Hide rather than collapse scrollbar thumb when scrollbar is disabled. r=NeilDeakin

Comment 12

3 months ago
Last Resolved: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Comment 13

3 months ago

re Comment 9
It seems to have been fixed in the latest Nightly 66.0a1 (2019-01-12) (64-bit)
Bearing in mind that the fix is minor, and it has to do with Frontend, and that FF65 is still nearly 3 weeks away, can't this be pushed for to FF65?

Flags: needinfo?(xidorn+moz)

Comment 14

3 months ago

Comment on attachment 9033058 [details]
Bug 1514498 - Hide rather than collapse scrollbar thumb when scrollbar is disabled. r?timdream

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1492012

User impact if declined: Developers may not see expected result in some cases with the scrollbar properties on Windows

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce:

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): It's a minor change to scrollbar style, shouldn't be risky.

String changes made/needed: n/a

Flags: needinfo?(xidorn+moz)
Attachment #9033058 - Flags: approval-mozilla-beta?

Comment on attachment 9033058 [details]
Bug 1514498 - Hide rather than collapse scrollbar thumb when scrollbar is disabled. r?timdream

[Triage Comment]
Minor scrollbar styling fix-up to ensure consistency with developer expectations. Approved for 65.0b11.

Attachment #9033058 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I successfully reproduced the issue on Firefox Nightly 66.0a1 (2018-12-15) under Windows 10 (x64) using the STR from Comment 0.

The issue is no longer reproducible under Firefox Beta 65.0b11 and latest Nightly 66.0a1 (2019-01-15) under Windows 10 (x64). I verified on Ubuntu 16.04 (x64) and macOS 10.12 too, just to make sure all is in order.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.