I've already posted this bug to Chromium bug tracker, and some users confirm that it also applies to Sway. But it seems like in Gnome everything works as expected. Is there any way to fix it on the system level? STEPS TO REPRODUCE 1.Run wayland session 2.Enable Preferred Ozone platform = auto flag 3.Open some PWA on Wayland, YouTube as instance 4.See that meta key, media keys and other global keyboard hotkeys are no longer working when PWA is focused EXPECTED RESULT Global hotkeys work as usual SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Operating System: KDE neon 5.25 KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.15.0-43-generic (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800HS with Radeon Graphics Memory: 22,9 GiB of RAM Graphics Processor: AMD RENOIR Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA401QE_GA401QE System Version: 1.0
https://bugs.chromium.org/p/chromium/issues/detail?id=1338554#c16 - it seems like chromium team is not going to fix this.
From the linked bug report: > On the other hand, Chrome's requirement is: > - first, (in some situations, like PWA), Chrome would like to process keys. > - If Chrome (incl. app) does not process it, then it would like to send back to the system (compositor) to let them process. That's not acceptable on Wayland, yeah. The explicit design is for the compositor to be in charge here. I guess we need to plead our case to the Chromium devs, or somehow work around it in KWin, if that's even possible.
I think it must be possible because gnome wayland is not affected. The fix can probably lead to some side-effects like chrome apps won't be able to handle some shortcuts (global ones maybe), but to be honest - I don't see any difference in chrome behavior between X11 and Wayland on Gnome, everything just works. There's also a workaround for Sway that can be investigated and probably ported to Kwin.
*** Bug 458836 has been marked as a duplicate of this bug. ***
(In reply to Komorebi from comment #3) > There's also a workaround for Sway that can be investigated and probably > ported to Kwin. The workaround for Sway seems to me to be the same thing as going to Kwin configuration Window Rules and setting up an app rule with the property "Ignore global shortcuts" - "Force" - "No". Unfortunately, this doesn't work. The same issue I have with the window rule property "No titlebar and frame" (Bug 453977). Apparently for these types of properties (boolean?) setting "Force" - "No" means "don't cause a change of behavior" instead of the expected "prevent the app from making this request", which seems wrong to me. IMHO, if Chrome PWAs actually issue the "Ignore global shortcuts" request - even unnecessarily - then kwin should honor that. But the user should have the option of telling kwin to stop honor such requests for misbehaving apps (like Chrome PWAs) - and the UI for that is already there, we just need it to work. Having that override would be a good resolution for this ticket, IMHO, and the "correct" fix can be left for upstream (i.e. Chrome/ium developers).
Upstream bug seems to have been fixed? I haven't verified yet.
(In reply to Oded Arbel from comment #6) > Upstream bug seems to have been fixed? > > I haven't verified yet. Verified for me on two computers running Chrome 110 and Plasma 5.26 with Wayland session. Appears to have been fixed upstream.
I also just verified with Wayland Plasma 5.27 and Google Chrome 110.