This is a problem we observed with chromium-browser and verified with Weston and kwin. Xwayland version is 1.18.4 Steps to reproduce: 1. Start a Wayland compositor with XWayland support 2. Start chromium-browser 3. Use shortcut to start new incognito instance (ctrl+shift+n) 4. Don't release the key combo immediately What happens: whenever the compositor passes keyboard focus to the new opened window the shortcut seems to get triggered again opening a new chromium window. This doesn't happen on regular X. It looks like the keys array on surface enter trigger another key press (or key repeat) event.
Also, I think that this is regression in between Xwayland version 1.18.0 to 1.18.4, given this issue started happening after upgrading packages to newer version.
I cannot reproduce here, using a build from current master, only one window gets opened. But that reminds me of of a couple of commits. 1. https://cgit.freedesktop.org/xorg/xserver/commit/?id=239705 2. https://cgit.freedesktop.org/xorg/xserver/commit/?id=fee0827 Both issues are addressed in master but not in 1.18. Would it be possible for you to either check with Xwayland from git master or try the branch "server-1.18-backports" from git://people.freedesktop.org/~ofourdan which contains those fixes backported to 1.18 (along with a few others)? (In reply to Bhushan Shah from comment #1) > Also, I think that this is regression in between Xwayland version 1.18.0 to > 1.18.4, given this issue started happening after upgrading packages to newer > version. If that's the case you should be able to identify the culprit with a git bissect.
> 1. https://cgit.freedesktop.org/xorg/xserver/commit/?id=239705 That one I had already looked at in git log and doubt it's related. It's before the key repeat happens. The second mentioned commit looks exactly like it could address the problem. Unfortunately I don't have a build env of xwayland setup, so testing might take some time. And I didn't find daily builds for my distro :-(
After some fighting with my system I was able to compile 1.18 branch with fee0827 cherry-picked and with that I'm not able to reproduce the issue any more. Unfortunately I failed with trying to compile master due to missing xfont2 on my distribution :-(
(In reply to Martin Gräßlin from comment #4) > After some fighting with my system I was able to compile 1.18 branch with > fee0827 > cherry-picked and with that I'm not able to reproduce the issue any more. Good news, so I guess we can close this bug? > Unfortunately I failed with trying to compile master due to missing xfont2 > on my distribution :-( It's just the newest version of libXfont for git master git://anongit.freedesktop.org/xorg/lib/libXfont
depends on whether there is going to be another 1.18 bug fix release or not. If there is another one I would say: backport, otherwise yes can be closed.
Closing as fixed a long time ago.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.