1659423 - [wayland] Mispositioned select popup in the new printing dialog

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Emilio Cobos Álvarez (:emilio)]

The dropdown is in the top left of the screen. Haven't debugged this yet.

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Emilio, can you post a screen please? Is that Wayland only? Is HiDPI involved?
Thanks.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: print-preview-dropwdown.png

Yes, wayland only. HiDPI is involved (window.devicePixelRatio = 2), but the position is so off that it doesn't seem like a coordinate space confusion. See the top left of the screenshot.

STR should be just on this page for example do Ctrl+P (or File > Print Preview), then click on the "Save to PDF" dropdown.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

I see. This may be caused by missing link between parent/child window so the dropdown is created as toplevel. We can't position toplevel windows on Wayland.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I cannot reproduce this anymore somehow?

Comment 6

[Darkspirit]

Gnome Wayland, Debian Testing, 2560x1440
Steps seem unchanged for me: Still reproducible with a maximized window.
$ MOZ_ENABLE_WAYLAND=1 mozregression --launch 2020-08-27 --pref gfx.webrender.force-disabled:true -a https://example.com

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Oh, indeed! I hadn't noticed this was maximized-screen only... That's odd.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1659423 - Also move wayland popup if getting sane popup dimensions. r=stransky,jhorak

What is going on is that nsComboboxControlFrame first positions the 0x0
widget, then sizes it. But when moving a 0x0 wayland popup, we just bail
out in NativeMoveResizeWaylandPopup().

So unless we also change the offset in some other way, and hit this
code:

https://searchfox.org/mozilla-central/rev/dc30fc92f2d02abe716426df7eff0f0bbb907da2/view/nsView.cpp#335

when updating the view tree (which doesn't happen with the maximized
window, and actually it's a bit questionable that it happens without it,
there may be some pre-existing coordinate space confusion there) we'll
end up in a plain Resize() rather than MoveResize(), and never position
the widget at the right place.

This doesn't happen for regular web content because the new print dialog
lives in the parent process (which uses nsComboboxControlFrame) rather
than on the child (which uses nsMenuPopupFrame).

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Finally got some time to dig into this.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de2ff8f555f0
Also move wayland popup if getting sane popup dimensions. r=stransky

Comment 11

[Razvan Maries]

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