Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1358700 - [Wayland] In rare cases, applications don't react to mouse input any more (but to keyboard events)
Summary: [Wayland] In rare cases, applications don't react to mouse input any more (bu...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: WaylandRelated
TreeView+ depends on / blocked
 
Reported: 2016-07-21 09:57 UTC by Christian Stadelmann
Modified: 2017-10-31 11:13 UTC (History)
26 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-31 11:13:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 763246 0 Normal RESOLVED Applications stop responding to mouse clicks, though menu bar remains responsive 2021-01-07 18:03:57 UTC

Description Christian Stadelmann 2016-07-21 09:57:51 UTC
Description of problem:
I rarely run into situations where most or all applications don't seem to get mouse input events any more. They still react to keyboard events. Gnome-shell still works fine handling my mouse events for its own UI. Switching to a tty and back makes this problem go away.

Version-Release number of selected component (if applicable):
libwayland-client-1.10.0-1.fc24.x86_64
xorg-x11-server-Xwayland-1.18.3-6.fc24.x86_64
mutter-3.20.3-1.fc24.x86_64
gnome-shell-3.20.3-3.fc24.x86_64
gtk3-3.20.6-1.fc24.x86_64
libinput-1.4.0-1.fc24.x86_64

How reproducible:
rarely, unknown how to do this

What I do:
click into an application: Buttons, menus, text fields, sliders, …

Actual results:
Nothing happens. All (or most?) applications don't get events or ignore them

Expected results:
Applications should get and handle mouse input.

Additional info:
Workaround: Switch to any tty and back. You don't need to login.

still unclear, I'll add this info once I can. If you can contribute this info, please do so:
* does it really affect all applications?
* I know I can use https://fedoraproject.org/wiki/How_to_debug_Wayland_problems to hunt down this issue, but I didn't have the chance to do it yet. Still I wanted to report this bug because it might be important and affect other people.

Comment 1 Christian Stadelmann 2016-07-21 17:34:32 UTC
See also bug #1358889, which is mostly the same but with mouse events working and keyboard events partially broken.

(In reply to Christian Stadelmann from comment #0)
> Additional info:
> Workaround: Switch to any tty and back. You don't need to login.

To be more precise: Ctrl+Alt+Fn to tty and back is enough to make this bug go away.

Comment 2 Christian Stadelmann 2016-07-24 18:05:35 UTC
I just ran into this bug again.

This time I had the chance to start a terminal and run `WAYLAND_DEBUG=1 nautilus` from it. Output shows that the application (nautilus in this case) doesn't get any mouse input at all, so I'm pretty sure this is an issue in the gnome-shell process, probably in mutter.

Comment 3 Chris McCabe 2016-07-25 03:34:27 UTC
I'm beginning to think that this is the cause for me when my mouse stops working:

Jul 24 20:29:03 mobile-linux org.gnome.Shell.desktop[1702]: (gnome-shell:1702): mutter-CRITICAL **: Failed to open pipe: Too many open files

Comment 4 Christian Stadelmann 2016-07-25 06:58:12 UTC
(In reply to Chris McCabe from comment #3)
> Jul 24 20:29:03 mobile-linux org.gnome.Shell.desktop[1702]:
> (gnome-shell:1702): mutter-CRITICAL **: Failed to open pipe: Too many open
> files

That's interesting, I'm seeing this message on my logs quite often lately. `ulimit -a` shows it is limited to 1024 files. I'll raise the limit and look whether this bug goes away.

Anyway, I think there is something wrong when my desktop session has 1024 files open, isn't that a bit too much?

Processes with most opened files¹:
* gnome-shell: about 500; 286 in /usr, 40 in /run, 13 in /dev, 63 times drm
* firefox
* evolution
* …

¹ numbers from `$ watch 'lsof -u username -n -P | awk '\''{print $2}'\'' | sort | uniq -c | sort -n -r'`, some files are counted twice, even per process.

Comment 5 Chris McCabe 2016-07-25 22:06:29 UTC
(In reply to Christian Stadelmann from comment #4)

I was trying to raise the open files limit, but I can't figure out how to do it. I modified /etc/security/limits.conf but it only affects root. Regular users are stuck at a hard limit of 4096. There must be something overriding it somewhere but I can't find it.

Comment 6 Christian Stadelmann 2016-07-26 05:49:29 UTC
Please note this comment line in /etc/security/limits.conf:

> Also note that configuration files in /etc/security/limits.d directory, which are read in alphabetical order, override the settings in this file in case the domain is the same or more specific.
> That means for example that setting a limit for wildcard domain here can be overriden with a wildcard setting in a config file in the subdirectory, but a user specific setting here can be overriden only with a user specific setting in the subdirectory.

And have you tried rebooting your system?

Comment 7 Chris McCabe 2016-07-26 13:29:05 UTC
(In reply to Christian Stadelmann from comment #6)
There are no files in /etc/security/limits.d and I have rebooted. After further investigation, I found that some processes, including gnome-shell, are getting the higher limits that I set, but most are stuck at 1024/4096 max open files, including 
gnome-terminal-server and dbus-daemon.

Comment 8 Christian Stadelmann 2016-07-26 16:12:47 UTC
Hm, I'm seeing the same. Don't know what's going on here.

Comment 9 Christian Stadelmann 2016-10-28 09:56:14 UTC
I'm seeing this bug (mouse events don't get to applications) on Fedora 25 with Gnome 3.22.1

Affected software versions:
gtk3-3.22.2-1.fc25.x86_64
glib2-2.50.1-1.fc25.x86_64
mutter-3.22.1-5.fc25.x86_64
gnome-shell-3.22.1-2.fc25.x86_64
libinput-1.5.0-1.fc25.x86_64
libwayland-client-1.12.0-1.fc25.x86_64


(In reply to Chris McCabe from comment #7)
> (In reply to Christian Stadelmann from comment #6)
> There are no files in /etc/security/limits.d and I have rebooted. After
> further investigation, I found that some processes, including gnome-shell,
> are getting the higher limits that I set, but most are stuck at 1024/4096
> max open files, including 
> gnome-terminal-server and dbus-daemon.

By the way, the ulimit bug is somewhere else: https://bugzilla.redhat.com/show_bug.cgi?id=1364332

Comment 10 Jonathan Haas 2016-11-21 13:17:27 UTC
I can reproduce that easily on F25 with a wayland session and it makes wayland unusuable. All XWayland applications will not react to mouse events anymore, native wayland applications continue to work fine.

Comment 11 Derek Cramer 2016-11-25 11:59:27 UTC
I just updated my work machine to F25 today and am seeing the same issue. I switched back to Xorg and the problems disappear.

It affected Xbindkeys, Firefox, Chrome, Gnome Terminal and Synergy. It may have affected more, but those are the ones that affected my work productivity.

Comment 12 Christoph Maser 2016-12-15 06:57:03 UTC
Seeing the same problem on F25. Switching to tty and back fixes it until it happens again. Saw this affecting xterm, evolution, firefox and other applications

Comment 13 Charles Oliver Nutter 2017-02-14 21:16:04 UTC
I'm running into this problem as well, and I'm a bit frustrated that this bug has been open for over six months with no responses from anyone that actually works on Wayland.

It is definitely only happening in Wayland. It also looks like it only affects XWayland apps, as J. Haas said above. I have no vtys configured so I can't use that workaround...the only way to get clicks back is to log out and in.

What can I do to debug? I want to keep using Wayland but this is a serious showstopper.

Comment 14 Charles Oliver Nutter 2017-02-14 21:22:40 UTC
I neglected to share local info. I'm on F25 running wayland, with all latest updates as of today Feb 14 2017.

Comment 15 Dietrich 2017-03-03 09:38:57 UTC
Hey,

same issue here F25 latest...

Another workaround that is not listed yet is just close all x11 windows then reopen what you need. At least for me this fixes the problem temporary.

Comment 16 Christian Stadelmann 2017-03-05 11:02:12 UTC
Happens about once in 6 hours of operations to me.

I am seeing this bug in all types of applications.

(In reply to Dietrich from comment #15)
> Another workaround that is not listed yet is just close all x11 windows then
> reopen what you need. At least for me this fixes the problem temporary.

Seems like XWayland catches the input and doesn't release it again.

Comment 17 Olivier Fourdan 2017-03-06 08:27:40 UTC
Could be an x11 client grabbing the pointer, that would affect only X11 applications and not Wayland native ones, and would prevent any pointer input to x11 clients.

Any particular application and/or use pattern that would exhibit that behavior?

Comment 18 John Whitley 2017-03-06 09:18:44 UTC
I would not describe this as rare.
 It happens regularly when (in my case) switching from workplaces that are used for development e.g. netbeans and terminal and into a workplace running firefox.
I would say roughly 1 in 5 switches.

Other usage does not seem to suffer.

Remedy is as above Cntrl-Alt F3, Cntrl-Alt F1 and login

Comment 19 Christian Stadelmann 2017-03-06 10:28:13 UTC
(In reply to Olivier Fourdan from comment #17)
> Any particular application and/or use pattern that would exhibit that
> behavior?

No particular applications, as far as I've tested any XWayland application is affected. I am not sure (and will report if I am) whether pure Wayland apps are affected.
No particular pattern.

There is a similar bug for keyboard input only, I've seen less often: https://bugzilla.redhat.com/show_bug.cgi?id=1358889

Comment 20 Dietrich 2017-03-06 22:29:10 UTC
I think it never happened for me when neither firefox nor thunderbird was open - but then again there is hardly any time that I do not have those open.

Comment 21 Dietrich 2017-03-06 22:50:54 UTC
Oh and usually some KDE-Apps are open when it happens

Full list:

kile
kbibtex
firefox
thunderbird
gnome-terminal

Comment 22 Jonas Ådahl 2017-03-07 02:58:08 UTC
FWIW, it looks like the same as the upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=763246

Comment 23 Matthew Miller 2017-03-22 14:15:14 UTC
Can someone confirm if the upstream bug fix fixes this?

Comment 24 Olivier Fourdan 2017-03-22 14:51:43 UTC
(In reply to Matthew Miller from comment #23)
> Can someone confirm if the upstream bug fix fixes this?

Those patches for mutter have been backported to gnome-3.22 branch upstream but have not been part of a mutter 3.22.x update yet, so they are not in f25 either.

FWIW, I ran a scratch build with the 4 relevant patches applied to mutter 3.22.3 for those who'd be willing to test on f25:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=18522460

Of course, this requires restarting the Wayland session (mutter/gnome-shell being the Wayland compositor)

As usual, being a scratch build, those packages will self destruct after a short period of time :)

Comment 25 Christian Stadelmann 2017-03-22 22:35:38 UTC
Since I do not have a reproducer, I will test the scratch build and wait for the bug to happen again. Just ask again in about 2 weeks.

Comment 26 Christian Stadelmann 2017-03-23 00:56:18 UTC
I can confirm the upstream patch partially fixes the behavior described in https://bugzilla.gnome.org/show_bug.cgi?id=763246#c29, but it introduces a new bug (drag and drop broken completely, see https://bugzilla.gnome.org/show_bug.cgi?id=763246#c48).

Comment 27 Olivier Fourdan 2017-03-23 08:21:18 UTC
(In reply to Christian Stadelmann from comment #26)
> [...] but it introduces a new bug (drag and drop broken completely, see
> https://bugzilla.gnome.org/show_bug.cgi?id=763246#c48).

"drag and drop broken completely" is not an accurate description, it works, see my reply https://bugzilla.gnome.org/show_bug.cgi?id=763246#c49

Comment 28 Jan Kurik 2017-03-23 16:07:44 UTC
During the "Prioritized bugs and issues" meeting we have postponed evaluation of this bug for the next meeting, to collect more thought on this.

Comment 29 Jan Kurik 2017-04-19 14:45:40 UTC
Removing the request for the Prioritized bug as there is already an upstream patch.
https://meetbot.fedoraproject.org/fedora-meeting/2017-04-19/fedora_prioritized_bugs_and_issues.2017-04-19-14.01.html

Comment 30 Andrea 2017-06-17 13:31:45 UTC
Using Fedora 25 fully updated as of 17/06/2017, GNOME.

For me the culprit seems to be VirtualBox.

Sometimes after clicking VB guest window I loose the mouse for 50% of the apps which I believe are the ones using XWayland (Firefox, Thunderbird, Antimicro), while GNOME Terminal, Software, RythmBox still react as expected.

Just found this bug report, and have not tried yet to switch to a console.

My previous solution was to close the guest (Win 10) saving the state and restarting it.

Comment 31 Michał Wróbel 2017-10-22 22:38:56 UTC
Happened to me just like in comment #30. 

Fedora 26, GNOME, VirtualBox. Closing the virtual machine fixed the issue.

Comment 32 Christian Stadelmann 2017-10-31 11:13:31 UTC
In reply to Andrea from comment #30 and Michał Wróbel from comment #31:
Yours are separate issues so you might want to open a separate bug report, probably against VirtualBox.

The upstream bug report has been closed as fixed for a while and the fix has landed in Fedora 26 since. Based on this, I am closing this bug report.


Note You need to log in before you can comment on or make changes to this bug.