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
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.
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
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
> 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.