Bug 97467

Summary:	Key press passed to new window of same X client
Product:	Wayland	Reporter:	Martin Flöser <mgraesslin>
Component:	XWayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED FIXED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	CC:	bhush94
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Martin Flöser 2016-08-24 12:10:31 UTC

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.

Comment 1 Bhushan Shah 2016-08-24 12:16:47 UTC

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.

Comment 2 Olivier Fourdan 2016-08-24 12:45:21 UTC

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.

Comment 3 Martin Flöser 2016-08-24 13:36:36 UTC

> 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 :-(

Comment 4 Martin Flöser 2016-08-25 06:45:47 UTC

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 :-(

Comment 5 Olivier Fourdan 2016-08-25 08:40:57 UTC

(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

Comment 6 Martin Flöser 2016-08-25 08:51:46 UTC

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.

Comment 7 Daniel Stone 2018-06-04 07:20:19 UTC

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.