1795066 - Ctrl+Tab popup doesn't show up on dual monitor set-up.

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

If I enable browser.ctrlTab.sortByRecentlyUsed:true, and open Firefox on Wayland on my right monitor, the Ctrl+Tab popup doesn't show up. This is a regression from bug 1783437, Martin can you look when you have the chance?

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f29f4ba8462120b365d383032a470a73144af242&tochange=cafd5d446af8e3ebdd218096f7f8e65c9093caa8

Comment 1

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

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

:stransky, since you are the author of the regressor, bug 1783437, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 2

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

Sure.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Actually it works today after a mutter update, so maybe it's a mutter bug that's been fixed upstream...

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Oh, nvm, I'm on an X11 session r/n...

Comment 5

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

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

Comment 6

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

AFAIK The ctrlTab dialog is supposed to be placed in center of screen. It's created as popup parented to toplevel window but we don't know our toplevel position so the ctrlTab dialog position on Wayland is purely random. The toplevel always looks like placed at 0,0 global coordinates.

Comment 7

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

As for this bug it looks like we use wrong coordinates based on recent monitor. We place the ctrlTab dialog relatively to toplevel but we use global coordinates according to monitor.

Comment 8

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

I've got slightly different mozregression range:
https://hg.mozilla.org/integration/autoland/rev/5abef032e22b7ea23e707fc12baf697f2b7bb2a5

But both looks a bit weird to me. On 104.0 the ctrl+tab popup is placed by nsWindow::Resize() regardless of monitor while layout coordinates are correct:

[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::Resize [371.000000,399.000000] -> [1170.000000 x 236.000000] repaint 1
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::ResizeInt w:2340 h:472
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   with move to left:742 top:798
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   ConstrainSize: w:2340 h;472
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::NativeMoveResize move 1 resize 1 to 371,399 -> 1170 x 236
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::NativeMoveResizeWaylandPopup Bounds 371,399 -> 1170 x 236 move 1 resize 1
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::WaylandPopupConfigure tracked 0 anchored 0
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   tracked in hierarchy 1
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   popup type Utility
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]: nsWindow::WaylandPopupGetPositionFromLayout
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   layout popup CSS anchor (0, 0) (x=22500, y=24180, w=0, h=0), margin (t=0, r=0, b=0, l=0) offset (-240,-240)
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:     after margins (x=22500, y=24180, w=0, h=0)
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:     final (x=750, y=806, w=0, h=0)
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   relative popup rect position [750, 806] -> [0 x 0]
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   parentRect gravity: 1 anchor gravity: 1
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   set size [1170, 236]
[Parent 132241: Main Thread]: D/WidgetPopup [7fd931bf2000]:   popup position changed from [0, 0] to [371, 399]

But latest nightly uses the same coordinates on nsWindow::Resize() and layout anchor:

[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::Resize [2144.000000,399.000000] -> [1463.000000 x 281.000000] repaint 1
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::ResizeInt w:2926 h:562
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   with move to left:4288 top:798
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   ConstrainSize: w:2926 h;562
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   resized 1 aSize [2926, 562] mLastSizeRequest [0, 0] mBounds [0, 0]
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::NativeMoveResize move 1 resize 1 to 2144,399 -> 1463 x 281
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::NativeMoveResizeWaylandPopup Bounds 2144,399 -> 1463 x 281 move 1 resize 1
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::WaylandPopupConfigure tracked 0 anchored 0 hint 0
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   tracked in hierarchy 1
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   popup type Utility
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]: nsWindow::WaylandPopupGetPositionFromLayout
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   layout popup CSS anchor (0, 0) (x=128880, y=24180, w=0, h=0), margin (t=0, r=0, b=0, l=0) offset (-240,-240)
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:     after margins (x=128880, y=24180, w=0, h=0)
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:     final (x=4296, y=806, w=0, h=0)
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   relative popup rect position [4296, 806] -> [0 x 0]
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   parentRect gravity: 1 anchor gravity: 1
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   set size [1463, 281]
[Parent 67849: Main Thread]: D/WidgetPopup [7facce522000]:   popup position changed from [0, 0] to [2144, 399]

so looks like there's a fix on layout side which includes correct monitor where the popup is placed but that breaks Wayland.

Comment 9

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

Err, looks like layout&Resize are the same.

Comment 10

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

Ahh, I found it. It works if the main FF window is not moved. When it's moved (before ctrl+tab) it's broken. Perhaps we propagate recent monitor info.

Comment 11

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

Attachment: Bug 1795066 [Wayland] Don't report monitor/screen shift to layout on Wayland r?emilio

We can't report monitor/screen shift to layout on Wayland. It causes wrong popup placement as all window/popup coordinates are used relatively to parent on Wayland.
Also we can't get/set position of toplevel windows on Wayland.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Is this ready to land? :)

Comment 13

[Emilio Cobos Álvarez (:emilio)]

(Thanks for fixing it btw!)

Comment 14

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

Landed, Thanks.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b5d3d446a23
[Wayland] Don't report monitor/screen shift to layout on Wayland r=emilio

Comment 16

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/7b5d3d446a23

Comment 17

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue with Firefox 107.0a1 on Ubuntu 22.04 - Wayland by following the infos provided in Comment 0.

The issue is no longer reproducible on Firefox 108.0b5 and Firefox 109.0a1.