1656786 - <select> list with more <option> elements than list size not scrollable anymore

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Firefox Nightly 81.0a1 20200802093514 on Windows 8.1

<select> lists with more <option> elements than list size are not scrollable anymore

Example: 'Product' list at https://bugzilla.mozilla.org/query.cgi?format=advanced

Comment 2

[Mats Palmgren (inactive)]

FYI, only mouse-scrolling is broken - scrolling using the keyboard works fine...

Comment 3

[Mats Palmgren (inactive)]

So, the issue seems to be that ScrollFrameHelper::WantAsyncScroll() depends on the style NOT being hidden to be "scrollable":
https://searchfox.org/mozilla-central/rev/72a1334982cadde0ca8b3d3583877afea80f5639/layout/generic/nsGfxScrollFrame.cpp#1477-1480
GetScrollStylesFromFrame() used to return the unmodified CSS style, but now (bug 1531609) we map it to auto/hidden/scroll:
https://searchfox.org/mozilla-central/rev/72a1334982cadde0ca8b3d3583877afea80f5639/layout/generic/nsGfxScrollFrame.cpp#4318-4319
and <select> has overflow:clip:
https://searchfox.org/mozilla-central/rev/72a1334982cadde0ca8b3d3583877afea80f5639/layout/style/res/forms.css#231
which maps to hidden:
https://searchfox.org/mozilla-central/rev/72a1334982cadde0ca8b3d3583877afea80f5639/layout/base/ScrollStyles.cpp#20-21

I can't say I really understand the logic behind treating hidden has "unscrollable" in ScrollFrameHelper::WantAsyncScroll() - why does it do that? (hidden is scrollable (by script) per the CSS spec and always has been...)

It makes no sense to me that GetScrollStylesFromFrame() should return anything but auto/hidden/scroll given that this is a scroll frame!

Comment 4

[Emilio Cobos Álvarez [:emilio]]

While overflow: hidden is scrollable, it's not scrollable by the user... It seems also wrong to show scrollbars for something with overflow: clip. Maybe we should have overflow: auto in the listbox rules in forms.css?

Comment 5

[Mats Palmgren (inactive)]

Yes, I clarified my comment above. What seems odd to me that ScrollFrameHelper::WantAsyncScroll would check the style at all since if you have a scroll frame it can be scrolled in one way or another... But I guess its real semantics is "CanBeScrolledByUser" or something like that...

Comment 6

[Mats Palmgren (inactive)]

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

That broke css/css-flexbox/select-element-zero-height-002.html.
Presumably clip is excluded from the logic that makes is shrinkable to zero size with auto/hidden/scroll.

Also, the test I added pass locally but apparently synthesizeWheel is unreliable...

On Android, it appears comboboxes depends on overflow:clip to clip away the down-arrow for appearance:none, otherwise it creates overflow.

Yikes, what a mess...

Comment 7

[Emilio Cobos Álvarez [:emilio]]

I'd add the overflow: auto to this rule instead, probably. That's where we create a scrollframe unconditionally isn't it? Comboboxes otherwise are blocks.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Bug 1656786 - Make <select> list have 'overflow:auto' by default to indicate its scrollable. r=emilio

Comment 9

[Mats Palmgren (inactive)]

Attachment: unreliable mochitest

Here's my attempt at writing a mochitest for this, for posterity...

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/164543a1bf04
Make <select> list have 'overflow:auto' by default to indicate its scrollable.  r=emilio

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/164543a1bf04