1968598 - Context menu won't show up after disconnecting an external display

Status: RESOLVED FIXED

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

Description

[674Y3r]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

Running Firefox Nightly on Void Linux with KDE Wayland (kwin-6.3.3).
Using only an external monitor (built-in one is disabled), then launching firefox and disconnecting the display (so that the built-in one is used instead and screen geometry changes, but works in both ways) breaks context/hamburger/extension menus making them impossible to use, unless firefox is restarted (if opened, new windows are also affected).

mozregression result:
33:29.15 INFO: Last good revision: 9a4078347e9ac9d673f78833fe247dd08ef2ee02
33:29.15 INFO: First bad revision: ad1382e084fc2ac35ee38f8f1fdfe3d5f218dc06
33:29.15 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9a4078347e9ac9d673f78833fe247dd08ef2ee02&tochange=ad1382e084fc2ac35ee38f8f1fdfe3d5f218dc06

Steps to reproduce:

• launch firefox,
• having only one display in use, disable an enabled one, so that the pc switches to the second one,
• open context/hamburger/extension menu.

Actual results:

Context menu doesn't show up after using rmb, hamburger/extension menu doesn't show up after clicking a button.

Expected results:

Context menu shows up after using rmb, hamburger/extension menu shows up after clicking a button.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Comment 3

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

:stransky, since you are the author of the regressor, bug 1959368, could you take a look?

For more information, please visit BugBot documentation.

Comment 4

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 5

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

Let's wait if Bug 1966639 helps here.

Comment 6

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

Can you please test latest nightly?
Thanks.

Comment 7

[674Y3r]

The issue is still here.
(latest build id: 20250603213222)

Comment 8

[Pascal Chevrel:pascalc]

I don't think we can ship 140 with this bug, Martin would it be safe to back out the regressor? Thanks

Comment 9

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

I'll look at it today. It's enough to just remove IsHDRMonitor() call from screen getter.

Comment 10

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

Attachment: Bug 1968598 [Wayland] Don't get HDR info from particular monitors r?emilio

Comment 11

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

This one uses the HDR info from Wayland protocol as before and it's suitable for uplift to beta.

Comment 12

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

It may also fix Bug 1968308.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b588667c41bd
https://hg.mozilla.org/integration/autoland/rev/0c10d3a38763
[Wayland] Don't get HDR info from particular monitors r=emilio

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://github.com/mozilla-firefox/firefox/commit/b588667c41bd314c1d0c3b6abfbdaad39aa5a14f
https://hg.mozilla.org/mozilla-central/rev/0c10d3a38763

Comment 15

[Pascal Chevrel:pascalc]

I confirm that this is fixed in nightly 20250608202551

Comment 16

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

Comment on attachment 9493207 [details]
Bug 1968598 [Wayland] Don't get HDR info from particular monitors r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Crashes/missing menu in Wayland with more than one monitor attached.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Removed Wayland specific HDR monitor sweep. returned to old protocol check.
• String changes made/needed:
• Is Android affected?: No

Comment 17

[Donal Meehan [:dmeehan]]

Comment on attachment 9493207 [details]
Bug 1968598 [Wayland] Don't get HDR info from particular monitors r?emilio

Approved for 140.0b8

Comment 18

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/e1b2520d940d
https://hg.mozilla.org/releases/mozilla-beta/rev/6168b07a1646

Comment 20

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

Copying crash signatures from duplicate bugs.