1640567 - Dropdowns with defined width collapse to width of text within dropdown

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Asif Youssuff]

Attachment: 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

Comment 1

[Asif Youssuff]

Attachment: bad-dropdown.png

Comment 2

[Asif Youssuff]

Attachment: good-dropdown.png

Comment 3

[Asif Youssuff]

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

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Jan Horak [:jhorak]]

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

Comment 6

[Pascal Chevrel:pascalc]

Wontfix for 77 as we build our RC today.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Didn't mean that Neil, fwiw :)

Comment 8

[Neil Deakin]

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

Comment 9

[Jan Horak [:jhorak]]

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

Comment 12

[Simone Marchioni]

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

Comment 13

[Jan Horak [:jhorak]]

Attachment: Bug 1640567 Pass expected window position to the NativeMoveResizeWaylandPopup to avoid repositioning; r=stransky

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.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f7052818df29
Pass expected window position to the NativeMoveResizeWaylandPopup to avoid repositioning; r=stransky

Comment 15

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/f7052818df29