Bug 107358

I take it that the pointer works fine for all other Wayland clients.

Can you please provide the output of "xinput list" when the issue occurs?

Do you see any MotionNotify events when hovering the "xev" window, ButtonPress/ButtonRelease events when clicking inside the "xev" window?

Can you reproduce with another Wayland compositor such as "weston"?

(In reply to Olivier Fourdan from comment #1)
> I take it that the pointer works fine for all other Wayland clients.
yes, gnome-terminal not affected.

> Can you please provide the output of "xinput list" when the issue occurs?
Before game launch
$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:15                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:15            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:15                    	id=8	[slave  keyboard (3)]

After game launch
$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:15                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:15            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:15                    	id=8	[slave  keyboard (3)]

> Do you see any MotionNotify events when hovering the "xev" window,
> ButtonPress/ButtonRelease events when clicking inside the "xev" window?
How check this?

> Can you reproduce with another Wayland compositor such as "weston"?
Under "weston" this issue not happens, but under "weston" I don't see the game (I hear only music from splash screen)

> Do you see any MotionNotify events when hovering the "xev" window,
> ButtonPress/ButtonRelease events when clicking inside the "xev" window?
oh sorry, understand.

When the game is running not any MotionNotify events are displayed when I hovering "xev" window and also ButtonPress/ButtonRelease events not happens.

Soorry, something's unclear, are the controls restored if you quit the game/close the window?

(In reply to Olivier Fourdan from comment #4)
> Soorry, something's unclear, are the controls restored if you quit the
> game/close the window?

yes of course
Mouse control not available only at a time when the game is running.

Created attachment 140812 [details]
Simple repruder showing normal behavior with grabs

(In reply to mikhail.v.gavrilov from comment #5)
> yes of course
> Mouse control not available only at a time when the game is running.

Then it's just that the games issues an grab on the pointer...

Xwayland is a Wayland client but also an Xserver, which behaves like any other Xserver for the X11 clients, so if a client (the game) issues an acive pointer grab on the pointer, no other X11 cleitns will receive pointer events, that's the purpose of a grab.

However, ther eis no active grabs in Wayland, so other Wayland native clients are not affected by the X11 grab issued by the X11 cleints, which matches exactly what you describe.

To demonstrate that, I attached a very simple reproducer written in gtk2.

If you compile and run that reproducer on Wayland/Xwayland, it will bejave the same, no other X11 client wil lreceive pointer events as long as the client is running, whereas other Wayland native clients will remain unaffected.

In other words, this is normal.

(In reply to Olivier Fourdan from comment #6)
> To demonstrate that, I attached a very simple reproducer written in gtk2.
> 
> If you compile and run that reproducer on Wayland/Xwayland, it will bejave
> the same, no other X11 client wil lreceive pointer events as long as the
> client is running, whereas other Wayland native clients will remain
> unaffected.
> 
> In other words, this is normal.

You even overdid it, the game did not block the keyboard.
But I admit you were able to recreate the same effect.

I do not understand why you think this behavior is normal.
In a multitasking environment, when one application can influence another it is perceived as a system vulnerability.
It also opens up a large field of activity of extortionists software and simply poorly written software, which will create the illusion that the computer is frozen.

When I studing several year ago Wayland architecture I thought that for each X11 application would used separate XWayland client this allow fix all XServer problems in modern systems. At that time it was a problem with Remmina which sometimes did not want to give away control of mouse and keyboard and I had to kill XServer every time through the console.

I think  this should be fixed in Wayland environment for all type of applications.

May be related:
When I click on a specific area in the Opera browser, click happens in steam client.
Demonstration: https://youtu.be/FaDqGf1-QEM

Also instead of Opera browser may be another X11 application.Only native wayland applications not affected ti this bug.

It's very annoying bug too.

On this video I show that hover not working on reload button in gmail, because of XWayland bug: https://youtu.be/RZ70m2HjZ2Q

(In reply to mikhail.v.gavrilov from comment #7)
> (In reply to Olivier Fourdan from comment #6)
> > To demonstrate that, I attached a very simple reproducer written in gtk2.
> > 
> > If you compile and run that reproducer on Wayland/Xwayland, it will bejave
> > the same, no other X11 client wil lreceive pointer events as long as the
> > client is running, whereas other Wayland native clients will remain
> > unaffected.
> > 
> > In other words, this is normal.
> 
> You even overdid it, the game did not block the keyboard.
> But I admit you were able to recreate the same effect.

I did not overdo it, I just reused an existing bit of code I use elsewhere to demonstate the effects of a active grab on a device on X11 (either keyboard or pointer).

> I do not understand why you think this behavior is normal.

It is normal because this is how X11 is designed, this is part of the protocol, applications can issue an active grab on input devices and block other clients from receiving input events:

$ man XGrabPointer

       The XGrabPointer function actively grabs control of the pointer and
       returns GrabSuccess if the grab was successful.  Further pointer events
       are reported only to the grabbing client.  XGrabPointer overrides any
       active pointer grab by this client.  If owner_events is False, all gen‐
       erated pointer events are reported with respect to grab_window and are
       reported only if selected by event_mask.  If owner_events is True and
       if a generated pointer event would normally be reported to this client,
       it is reported as usual.  Otherwise, the event is reported with respect
       to the grab_window and is reported only if selected by event_mask.  For
       either value of owner_events, unreported events are discarded.

> In a multitasking environment, when one application can influence another it
> is perceived as a system vulnerability.

That's why we came up with Wayland.

> It also opens up a large field of activity of extortionists software and
> simply poorly written software, which will create the illusion that the
> computer is frozen.

Again, works as designed/intended.

> When I studing several year ago Wayland architecture I thought that for each
> X11 application would used separate XWayland client this allow fix all
> XServer problems in modern systems. At that time it was a problem with
> Remmina which sometimes did not want to give away control of mouse and
> keyboard and I had to kill XServer every time through the console.

No, we do not spawn an Xwayland server per X11 client, that would break inter-client communication between X11 clients, things like copy/paste, drag and drop etc. would not work with such a design.

> I think  this should be fixed in Wayland environment for all type of
> applications.

Sure, this is why we have Wayland, but these applcations you mention are not using Wayland, thery are still using X11.

If you want this to be fixed, please ask the developers of all these applications to port their application to Wayland instead.

Does the same issue happen on a plain Xorg session? If it does, I don't think there is anything we can do, as it, as Olivier pointed out, is how X11 is designed to work. If the issue do not reproduce on plain Xorg sessions, it might be that there is something we don't do on the Wayland session that would normally happen that the game uses to release the grab it took.

(In reply to Olivier Fourdan from comment #10)
> It is normal because this is how X11 is designed, this is part of the
> protocol, applications can issue an active grab on input devices and block
> other clients from receiving input events:

And you don't plan redesign X11 clients behaviour under Wayland environment?

> No, we do not spawn an Xwayland server per X11 client, that would break
> inter-client communication between X11 clients, things like copy/paste, drag
> and drop etc. would not work with such a design.

But possible also redesign inter-client communication between X11 clients and make similar to Wayland client.

> Sure, this is why we have Wayland, but these applcations you mention are not
> using Wayland, thery are still using X11.
> 
> If you want this to be fixed, please ask the developers of all these
> applications to port their application to Wayland instead.

It does not depend from our desire. And to desire this is look like to desire peace in the whole world. The world will never be perfect and the world of software too. But we can improve it if start spawn an Xwayland server per X11 client.

(In reply to Jonas Ådahl from comment #11)
> Does the same issue happen on a plain Xorg session? If it does, I don't
> think there is anything we can do, as it, as Olivier pointed out, is how X11
> is designed to work. If the issue do not reproduce on plain Xorg sessions,
> it might be that there is something we don't do on the Wayland session that
> would normally happen that the game uses to release the grab it took.

Yes, it reproduced under plain Xorg session, but as I described above it possible fixed under Wayland environment.
If you do not want to consider this as bug, then possible suggest this report as feature request for X11 clients in Wayland environment.
Because these old problems will not go away by themselves.

P.S. Is someone already looked at my video from 8 and 9 comment?
I don't know how reproduce it.
But it really often happens and spoils the nerves.

(In reply to mikhail.v.gavrilov from comment #12)
> (In reply to Olivier Fourdan from comment #10)
> > It is normal because this is how X11 is designed, this is part of the
> > protocol, applications can issue an active grab on input devices and block
> > other clients from receiving input events:
> 
> And you don't plan redesign X11 clients behaviour under Wayland environment?

No, because the purpose of Xwayland is precisely to allow legacy X11 clients to run unchanged on a Wayland compositor.

In theory, it would be possible to change Xwayland to pretend a grab succeeded but not actually issue the active grabs even when the clients request it, but that will break those X11 clients that rely on grabs to work.

Besides, not all clients can be ported/redesigned. There are old, legacy, closed source, in-house software that nobody knows how to recompile that run on X11 for years and will never be ported to Wayland, this is where Xwayland comes into play. For those, we want Xwayland to behave like any other X11 server.

If developers on such X11 clients had to redesign X11 clients for Wayland, they'd rather spend their time porting to Wayland native instead, I reckon.

(In reply to mikhail.v.gavrilov from comment #12)
> P.S. Is someone already looked at my video from 8 and 9 comment?
> I don't know how reproduce it.
> But it really often happens and spoils the nerves.

That's unrelated to this bug, it's a different problem.

I heard of similar issue with the Steam client, but this unclear to me if this is a compositor (gnome-shell/mutter) bug or Xwayland. Looks like the input region does not match the client window.

If you can reproduce at will with gnome-shell, can you try to reproduce in weston?

(In reply to Olivier Fourdan from comment #13)
> In theory, it would be possible to change Xwayland to pretend a grab
> succeeded but not actually issue the active grabs even when the clients
> request it, but that will break those X11 clients that rely on grabs to work.

How many clients or cases we know when grabs really needed?
I think the lesser of the evils is to break them, and not make the system vulnerable.

(In reply to mikhail.v.gavrilov from comment #15)
> (In reply to Olivier Fourdan from comment #13)
> > In theory, it would be possible to change Xwayland to pretend a grab
> > succeeded but not actually issue the active grabs even when the clients
> > request it, but that will break those X11 clients that rely on grabs to work.
> 
> How many clients or cases we know when grabs really needed?
> I think the lesser of the evils is to break them, and not make the system
> vulnerable.

A large portion would probably be Steam games. I've seen games that map two windows, grab input on one, then render on the other. I assume such setups would break, while being valid X11 clients.

(In reply to Jonas Ådahl from comment #16)
> A large portion would probably be Steam games. I've seen games that map two
> windows, grab input on one, then render on the other. I assume such setups
> would break, while being valid X11 clients.

The situation will never improve if everything is left as it is.
If discard active grab then there is a chance that the developers of such programs start looking for more correct ways of interacting with the user.

Another case:
You are working through Citrix ICA client which active grab mouse and keyboard. And your Skype, Hangout or maybe SIP client begin ring. And due of active grab you can't answer to this call. Perhaps it was be a recruiter which wanted to invite you to an interview for the work of your dream. But you missed this call and your dream crashed because you are an enthusiast and are sitting on Linux.

We can scold developers of SIP clients who have not made Wayland version in 2050 year or developers of the crooked Citrix client, but it will not make Linux users happier because they have to live with the architecture that for some reason was inherited from applications of DOS era.

FWIW, I think this bug should be closed as "NOTABUG", Xwayland is working as expected here.

(In reply to Olivier Fourdan from comment #18)
> FWIW, I think this bug should be closed as "NOTABUG", Xwayland is working as
> expected here.

I am agree with you it's no XWayland problem.
I am also understand your not desire deal with old Xorg code.
But this vulnerability should be fixed in Xorg code even by violating backward compatibility in next Xorg version.
We're all waiting for the X11 applications die by their own deaths, but it's too long process and all this time the Linux desktop will be worse than the Windows and MacOS desktop.

I suggest reassign this issue to Xorg developers and create CVE.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/725.