Select element is broken with Windows proton context menus
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | verified |
People
(Reporter: mmis1000, Assigned: emilio)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [proton-context-menus])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Steps to reproduce:
Make a select element that is long enough to get a scrollbar
<select name="birthdate_y" id="birthdate_y">
<option value="001">001</option>
<option value="002">002</option>
<option value="003">003</option>
...repeat about 100 time
<option value="103">103</option>
<option value="104">104</option>
<option value="105">105</option>
<option value="106">106</option>
<option value="107">107</option>
<option value="108">108</option>
<option value="109">109</option>
<option value="110">110</option>
</select>
Actual results:
Every Option is hidden, make it completely unusable.
Expected results:
I can see the option
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Assignee | ||
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Neil or Emilio, are you in a position to look into this? It feels like the sizing of the selectbox should account for the additional padding here somehow, but I'm not sure how that logic works.
Comment 3•3 years ago
|
||
I'm assuming that the button part of the <select> is computed too small. I would guess that the <select> element layout in nsComboboxControlFrame is basing its computations on the size of the nsListControlFrame, which doesn't have any of the proton styling. Since the listbox in a dropdown <select> never actually gets rendered in a content process, maybe the styles should just be changed in forms.css to match the proton style? I don't know how feasible that would be.
As an alternative, you could add some value to the rectangle corresponding to the extra padding supplied to SelectParentHelper.open, but the dropdown menu would then be larger than the button part.
Isn't the proton style on the mac already have a drop down wider than select itself?
Or that isn't intentional and actually another layout issue caused by the proton restyle?
Comment 5•3 years ago
|
||
(In reply to mmis1000 from comment #4)
Isn't the proton style on the mac already have a drop down wider than select itself?
Yes, but it appears on top of the select box, so it's much less obvious than to have a dropdown underneath an anchor that is off-by-N-px in terms of matching the width. The macOS styling is not a proton effect.
We could also reduce the padding on the items for the select dropdown case...
Assignee | ||
Comment 6•3 years ago
|
||
We shouldn't touch forms.css
for this. I'll look into this.
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
This allows nsMenuFrame::SizeToPopup to properly account for scrollbar width, by finding the real
scrollbox.
Assignee | ||
Comment 9•3 years ago
|
||
The issue was that that overflow: hidden
was creating a scrollframe that didn't have scrollbars, so this code ended up with no scrollbar width and the sizing didn't account for it. overflow: clip
allows clipping without having a scrollframe, so let's use that.
nsMenuPopupFrame::GetScrollFrame
is really lame indeed.
Comment 11•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7129a90db1f2 Use overflow:clip rather than overflow:hidden for proton menus. r=Gijs
Updated•3 years ago
|
Comment 12•3 years ago
|
||
bugherder |
Comment 13•3 years ago
|
||
Reproduced the issue mentioned in comment 0 using Firefox 89.0a1 (BuildId:20210413214314) on Windows 10 64bit.
This is verified fixed using Firefox 89.0a1 (BuildId:20210414160838) on Windows 10 64bit, macOS 10.15 and Ubuntu 18.04 64bit.
Description
•