Closed Bug 1704841 Opened 3 years ago Closed 3 years ago

Select element is broken with Windows proton context menus

Categories

(Core :: Layout: Form Controls, defect)

Firefox 89
Desktop
Windows 10
defect

Tracking

()

VERIFIED FIXED
89 Branch
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

OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop

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.

Component: Untriaged → Layout: Form Controls
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Severity: -- → S1
Flags: needinfo?(enndeakin)
Flags: needinfo?(emilio)
Summary: Select element is broken after proton design → Select element is broken with Windows proton context menus
Whiteboard: [proton-context-menus]

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.

Flags: needinfo?(enndeakin)

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?

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

We shouldn't touch forms.css for this. I'll look into this.

Assignee: nobody → emilio
See Also: → 1704174

This allows nsMenuFrame::SizeToPopup to properly account for scrollbar width, by finding the real
scrollbox.

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.

Flags: needinfo?(emilio)
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
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

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.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: