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

Status: VERIFIED FIXED

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

Description

[Alexandre Alapetite]

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:
https://alexandre.alapetite.fr/divers/vrac/20181215-Gecko-overflow-scrollbar-thin.html



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).

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Hmm, wfm on Linux. Xidorn, can you take a look on Windows?

Comment 2

[Alexandre Alapetite]

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

Comment 3

[Alexandre Alapetite]

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
	div.style['overflow-y'] = 'scroll';	//then force scrollbar refresh
	setTimeout(function () { div.style['overflow-y'] = ''; }, 0);	//and back to default
}

Comment 4

[Xidorn Quan [:xidorn] UTC+11]

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...)

Comment 5

[Xidorn Quan [:xidorn] UTC+11]

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

[Xidorn Quan [:xidorn] UTC+11]

Attachment: testcase

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

Attachment: Bug 1514498 - Hide rather than collapse scrollbar thumb when scrollbar is disabled. r?timdream

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 8

[Xidorn Quan [:xidorn] UTC+11]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ad9be400b3460e3f23e0adf1c4dfc46c0cff5e5d

Comment 9

[erosman]

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.

Comment 10

[Xidorn Quan [:xidorn] UTC+11]

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!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/15895cfafac1
Hide rather than collapse scrollbar thumb when scrollbar is disabled. r=NeilDeakin

Comment 12

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/15895cfafac1

Comment 13

[erosman]

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?

Comment 14

[Xidorn Quan [:xidorn] UTC+11]

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

Comment 15

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7ddc13a7de8d

Comment 17

[Catalin Sasca, Desktop QA [:csasca]]

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.