2088176 - [KDE] Popup panels (permission prompts, extension install prompt) don't appear on Wayland when gfx.color_management.hdr is true

Status: RESOLVED DUPLICATE of bug 2079668

(Core :: Widget: Gtk, defect)

Description

[Eugene]

Attachment: output graphic details from about:config

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

Steps to reproduce

Environment: Firefox 159.0, Fedora 44, KDE Plasma 6.8.2 (KWin 6.8.2), Wayland session, Mesa 26.2.5, AMD Radeon RX 6600, two monitors: 2560x1440@180Hz (scale 1.15) and 1920x1080@180Hz (scale 1.0).

1. Open about:config and set gfx.color_management.hdr to true (default is false).
2. Restart Firefox.
3. Open a site that requests microphone access, or start installing an extension from addons.mozilla.org.

Actual results

The popup panels never appear on screen. When a site requests microphone access, the microphone icon in the address bar is highlighted (the prompt is pending), but no popup is shown. When installing an extension, the puzzle-piece icon in the toolbar is highlighted in the same way, but the install prompt popup is not shown. So the prompts exist, but their popup panels are not displayed and can't be answered.

Setting gfx.color_management.hdr.force_enabled to true instead gives the same result. It happens on both monitors, with and without fractional scaling.

Setting the pref back to false and restarting fixes it immediately.

What I ruled out:

• Works with MOZ_ENABLE_WAYLAND=0 (XWayland).
• Works in a fresh profile (pref at default), and in Troubleshoot (Safe) Mode.
• Disabling all extensions in the affected profile does not help.

The attached about:support (Graphics section) was captured with the pref at its default value, i.e. when the problem is not present.

Expected results

The permission and install panels open and respond to clicks regardless of the HDR color management pref.

Comment 1

[BugBot [:suhaib / :marco]]

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

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

I don't see that on Gnome - will check KDE. But I haven't seen any similar reports so I wonder what's wrong there.

Can you please try latest nightly?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 3

[Eugene]

Attachment: Снимок экрана_20261103_182610.png

Comment 4

[Eugene]

Attachment: Снимок экрана_20261103_182644.png

Comment 5

[Eugene]

Hi Martin,

I tested the issue using the official Mozilla Firefox Nightly 161.0a1 Linux x86_64 build, with a fresh, separate profile.

Environment:

• Fedora Linux 44
• KDE Plasma (Wayland)
• Official Mozilla Firefox Nightly 161.0a1
• MOZ_ENABLE_WAYLAND=1

With gfx.color_management.hdr = true:

1. Microphone permission prompt: The microphone icon in the address bar becomes highlighted, but the permission popup never appears.
2. Extension installation prompt: The extension/puzzle-piece icon becomes highlighted, but the installation confirmation popup does not appear.
3. Window movement: The browser window moves slightly when dragged, but further attempts to move it fail.
4. Mouse pointer coordinates: After moving the window, the clickable areas no longer match their visual positions. For example, hovering over the Reload button highlights the Maximize button instead. To interact with Reload, I have to move the pointer approximately 30–50 pixels down and to the right of its visible position.

With gfx.color_management.hdr = false:

All the above issues disappear. Permission prompts and extension installation dialogs appear normally, the window can be moved freely, and mouse pointer coordinates match the visible interface.

The issue is therefore reproducible in a clean profile using an official Mozilla Nightly build, not just the Fedora-packaged Firefox.

I can provide screenshots or additional diagnostic information if needed.

Thanks!

Comment 6

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

Yes, I can see it too. Looks like HW accelerated popups are not shown on KDE. Gnome works correctly.
It seems to affects popups backed by EGL only.

Comment 7

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

I wonder if Bug 2087615 is related.

Comment 8

[Netflate]

Shouldn't be, EGL popups don't use wl_shm so they can't go through udmabuf

Comment 9

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

I don't have a good explanation for it. Is is possible that KDE fails to render EGL based wl_subsurface when it's attached to SHM backed wl_subsurface? But this bug affects popups only...will try mozregression.

Comment 10

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

Mozregression pointed out at Bug 2070729 which makes sense here.

Comment 11

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

It's reproducible even without HDR. But affects only automated popup open for me - when it's opened by user action it's shown.
So it's dupe of Bug 2079668.

Comment 12

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

Let's focus on Bug 2079668.