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

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Emilio Cobos Álvarez (:emilio)]

This is bug 1795066 but on KWin, regressed by bug 1824552.

I guess the fix for the "get screen for window" code-path uncovered this on ScreenGetterGtk.

Comment 1

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

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

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1851225 - Don't report screen shift in ScreenHelperGTK. r=stransky

This is basically bug 1795066, but for the non-ScreenGetterWayland
code-path.

Properly supporting GetWidgetScreen in ScreenGetterGTK caused this to
surface in environments where we'd otherwise reported the primary
monitor (which usually starts at 0, 0).

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9351253 [details]
Bug 1851225 - Don't report screen shift in ScreenHelperGTK. r=stransky

Beta/Release Uplift Approval Request

• User impact if declined: Comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Restores the behavior that GNOME had since bug 1795066.
• String changes made/needed: none
• Is Android affected?: No

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/21f64c0fc945
Don't report screen shift in ScreenHelperGTK. r=stransky

Comment 5

[pallaswept]

Also seeing this. KDE Wayland.

status-firefox117: --- → unaffected

I'm on 117 and it's effecting me and was also in 116.

This is bug 1795066

Ironically it's the reverse for me. Setting that parameter to true (and maximizing the window) is the only way I can see the popup. That bug says setting it to true is what breaks it, but for me it's the only partial workaround. I know of this only because you mentioned that bug so I set it to false (I usually have it true) and then the popup was ALWAYS off screen.

I have a 1440p display to the right and above a 1080p display. The popup is positioned such that when the window the popup is off-screen. Inspector shows me that the bottom is set to -336px, obviously off-screen.
When the window is not maximized or maximized, changes the behaviour. If I un-maximize the window and make it small enough and move it to the top of the display, I can just see the top part of the popup and the bottom of it is off-screen. The shorter I make the window, the further down it goes off-screen until the window is short enough and then the popup appears on the wrong display. When I place a window on the 1440p monitor, it still uses the 1980px width of the other display, so is off-centre to the left (doesn't fill the right side of the display). It's just all kinds of wrong.

Userchrome fails to save the day since it's all overwritten by the js. It seems as if it's using js to position the popup with relation to the display configuration rather than just using CSS to put it in the middle of the viewport (why!? (that's a rhetorical question...)) and is getting the calculation of the display area wrong.

the primary monitor (which usually starts at 0, 0).

But often doesn't. Mine usually starts at 1920,-540, but it changes depending on what I'm doing, sometimes it's 1920,540, sometimes 0,0, sometimes 0,-540. I wish I had a dollar for every bug I've seen that stemmed from assuming that the primary display is on the left and level with the secondary and statically positioned. I'd send it to you guys since I love firefox and you'd all like a new ferrari or whatever that kind of money could buy, but this bug is annoying as heck. Combine it with the fact that the all tabs list is also broken when you have too many tabs open and changing tabs is literal guesswork.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Setting that parameter to true (and maximizing the window)

That parameter to true is the thing that enables that feature, so it being true is a prerequisite for that popup to show up.

status-firefox117: --- → unaffected

That's because bug 1795066 only touched code that was executed in GNOME. I wasn't aware of this being an issue on KDE before my patch, but it makes sense that it could with some weird screen setups.

In any case my patch should fix it for good in KDE and GNOME (and everything ideally).

Comment 7

[pallaswept]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

That parameter to true is the thing that enables that feature, so it being true is a prerequisite for that popup to show up.

Wait, so if people don't sort by recent, they just get no popup with preview thumbnails at all? Sucks to be them. It should still do the popup, just in the other order. Doesn't bother me personally, but that does suck for them.

status-firefox117: --- → unaffected

That's because bug 1795066

This bug is marked as unaffected in 117, but it definitely effects 117.

In any case my patch should fix it for good in KDE and GNOME (and everything ideally).

Awesome, thank you!!

I'm gonna start daily-driving FF nightly again, it's the only way to get a working browser without waiting for months for important patches like yours to hit, and has a serious break so rarely that it's the only sane route. Ironic that the nightly version is more stable over time than the stable release, but since bugs stay in stable until the next stable, but that's just the way it is - plus as well as getting me fixes sooner, it gives me a chance to catch bugs like this sooner and report them sooner.

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/21f64c0fc945

Comment 9

[Pascal Chevrel:pascalc]

Comment on attachment 9351253 [details]
Bug 1851225 - Don't report screen shift in ScreenHelperGTK. r=stransky

Approved for 118.0b5, thanks.

Comment 10

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/13c686b59c49

Comment 11

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/13c686b59c49

Comment 12

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I was able to reproduce the issue on Firefox 118.0b2 on Kubuntu 22.04 Wayland session.

The issue is fixed on Firefox 118.0b5 and Firefox 119.0a1 (2023-09-06) on the same system.