Closed Bug 1640567 Opened 2 years ago Closed 2 years ago

Dropdowns with defined width collapse to width of text within dropdown

Categories

(Core :: Widget: Gtk, defect)

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- wontfix
firefox76 --- unaffected
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- fixed

People

(Reporter: yoasif, Assigned: jhorak)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(4 files)

Attached file form.html

See attached testcase.

Click the dropdown and observe that the width of the dropdown is not applied to the dropdown when opened.

61:20.99 INFO: No more integration revisions, bisection finished.
61:20.99 INFO: Last good revision: b3dc4544df1f551d462e4ff6559c37b72b8269b6
61:20.99 INFO: First bad revision: e09151714b9857a9f2e4e23cc22e921016299db4
61:20.99 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b3dc4544df1f551d462e4ff6559c37b72b8269b6&tochange=e09151714b9857a9f2e4e23cc22e921016299db4

Attached image bad-dropdown.png
Attached image good-dropdown.png
Has Regression Range: --- → yes
Regressed by: 1623974

Jan, it looks like your patch regressed this - can you take a look? Sorry if my regression range is bad. Thanks!

Flags: needinfo?(jhorak)

Set release status flags based on info from the regressing bug 1623974

Yes, it's my issue. Thanks for the report.

Little background:

  1. Apps under wayland cannot obtain absolute position on the screen.
  2. to avoid showing popups outside of the screen the application is supposed to give the (desktop) compositor hint with the anchor rect is and what to do when popup does not fit (flip, slide, resize).
  3. compositor calls a callback where the window has been placed and what is its new size

Neil: the problem is that I use NotifyWindowMoved [1] for updating popup position in the callback and this leads to setting the anchor type to the MenuPopupAnchorType_Point and later with SetPopupPosition the width of the parent frame is not used. It also leads to more problems like when clicking on hamburger menu button the hamburger menu is reappearing and not hiding every second time.

My question is: isn't there a better method to update position of the popup window without retriggering the nsMenuPopupFrame code? Like just updating the view by nsView::SetPosition (which I tried, but it does not work for the remote content).

[1] https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#1484
[2] https://searchfox.org/mozilla-central/source/layout/xul/nsMenuPopupFrame.cpp#2321

Flags: needinfo?(jhorak) → needinfo?(neil)

Wontfix for 77 as we build our RC today.

Didn't mean that Neil, fwiw :)

Flags: needinfo?(neil) → needinfo?(enndeakin)

[1] https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#1484
[2] https://searchfox.org/mozilla-central/source/layout/xul/nsMenuPopupFrame.cpp#2321

If nsMenuPopupFrame::MoveTo is called, then the popup is no longer anchored at the parent window, is detached from the parent, and is instead positioned at a specific screen coordinate where it was moved to.

If you want it to stay anchored, you need to instead not call MoveTo. I assume that this is coming from nsXULPopupManager::PopupMoved?

So is the implicaation here that we request a coordinate and gtk/wayland will move and resize to popup itself and expects to tell us what it really set the popup to? I'll need to think more about what that would mean.

Flags: needinfo?(enndeakin)

(In reply to Neil Deakin from comment #8)

[1] https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#1484
[2] https://searchfox.org/mozilla-central/source/layout/xul/nsMenuPopupFrame.cpp#2321

If nsMenuPopupFrame::MoveTo is called, then the popup is no longer anchored at the parent window, is detached from the parent, and is instead positioned at a specific screen coordinate where it was moved to.
Yes, that's what I also noticed

If you want it to stay anchored, you need to instead not call MoveTo. I assume that this is coming from nsXULPopupManager::PopupMoved?

Exactly.

So is the implicaation here that we request a coordinate and gtk/wayland will move and resize to popup itself and expects to tell us what it really set the popup to? I'll need to think more about what that would mean.
Basically under Wayland we pass the popup placement to the gtk.

The nsWindow will get some expected popup location, but we don't use them, we use anchorRect from nsMenuPopupFrame and placement flags - like shift, flip, resize to give compositor hints where the window should be located. The firefox is later notified by compositor where the window was placed and we need to use these values to set view? or frame(s)? correctly.

Flags: needinfo?(enndeakin)
Severity: -- → S3
Duplicate of this bug: 1644161
Blocks: wayland
Has STR: --- → yes
Component: Layout: Form Controls → Widget: Gtk
Duplicate of this bug: 1650577

Hi to all,

I write this message only to report that IMHO this bug is more severe than reported here.
It make web app unusable when there are HTML selects with scrollbars, since it is not possible to select all the options.
I had to switch to Chromium for that.

The problem is present in Firefox 77, 78, 79, and I don't know if it will be fixed in 80.

The severity is S3 => (Normal) Blocks non-critical functionality and a work around exists, but I can't see any workaround and for me is really a blocker to continue to use Firefox, so I think an S2 would be much more appropriate.

Just my 2C

If the position expected position of popup is not changed by the GTK (it popup fit into the screen)
we don't have to update position of nsMenuPopupFrame in Gecko view. We sent the anchor position
instead of expected popup position to the NativeMoveResizeWaylandPopup which triggered the view changes.

Assignee: nobody → jhorak
Status: NEW → ASSIGNED
Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f7052818df29
Pass expected window position to the NativeMoveResizeWaylandPopup to avoid repositioning; r=stransky
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
You need to log in before you can comment on or make changes to this bug.