Bug 99235 - Problem with intellij IDEs: Mouse click are blocked on Gnome on Wayland
Summary: Problem with intellij IDEs: Mouse click are blocked on Gnome on Wayland
Status: RESOLVED NOTOURBUG
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: 1.5.0
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-31 05:08 UTC by Daniel Rowe
Modified: 2017-03-10 08:10 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Error log generated by Android Studio which is based on IntelliJ Idea. (169.80 KB, text/x-log)
2017-01-29 03:22 UTC, Krishnan
Details

Description Daniel Rowe 2016-12-31 05:08:26 UTC
I use PyCharm and Android Studio on Fedora 25 with Wayland an am seeing strange input issues.

Basically stops responding on mouse clicking and it seems to block other apps.

After a while input goes all funny with the IDEs. If I switch VTs and got back to the Wayland VT the issue is fixed for a while. Closing the IDEs also fixes it.

Something strange with libinput, XWayland and the intelliJ IDEs?
 
Generally the experience with Wayland has been very good for me, for except this so far.

This may well be a intelliJ IDE issue but just in case I have raised this.

A issue has also been raised with JetBrains.

libinput.x86_64                                                       1.5.3-1.fc25
Comment 1 Peter Hutterer 2017-01-03 01:12:12 UTC
Do you see this in any other application, specifically native Wayland ones? Or any other applications used through XWayland?

This sounds like a stuck grab is is likely triggered by XWayland and IntelliJ somehow.
Comment 2 Daniel Rowe 2017-01-03 01:22:27 UTC
This is the bug raised with Jet Brains:

https://youtrack.jetbrains.com/issue/IDEA-162804
Comment 3 Daniel Rowe 2017-01-03 01:23:14 UTC
I only see this with the intelliJ IDEs.
Comment 4 Peter Hutterer 2017-01-03 01:56:59 UTC
but you didn't see it under X right, only through XWayland? That's likely either a bug in XWayland or in mutter then, question is which one...
Comment 5 Daniel Rowe 2017-01-03 01:58:36 UTC
Yes correct no problems under a X session at all with these apps.

If there is a way to debug let me know and Ill try and help.
Comment 6 Peter Hutterer 2017-01-03 02:01:50 UTC
See if you can figure out a reliable test case that reproduces the issue, then we can look at event streams, etc. Ideally as short as possible and as descriptive as possible so we can reproduce it here. See if it it reliably triggers on some UI element, etc. Anything that reduces the guesswork :)
Comment 7 Daniel Rowe 2017-01-06 10:21:54 UTC
OK so the best I can see is it does it while editing in the code window and then moving away from the PyCharm window.

Editing code fine, then move away to a different app and find it not accepting inputs.

For example working with PyCharm (latest version) on a flask app editing a .py file. Was in PyCharm for 10 mins or so.

I then went to the favourites icon bar, by moving mouse to top left corner of the screen and launched Virt Manager by clicking on a short cut I have for it on the bar which launched Virt Manager and I then noticed that I could not use Virt Manger and it had been triggered. When to other apps and also blocked, went back to PyCharm also blocked.

Did the changing VTs trick and fixed.

Tried the same action again, editing, moving away and launching the same app, but it did not do it. So it not repeatable, but it does apper to be when moving away to a different window.

Ill carry on and try to see if I can spot a pattern.
Comment 8 Daniel Rowe 2017-01-07 02:22:40 UTC
I have worked out what it is and are able to get it to do it 100% of the time.

In PyCharm (or any intelliJ based IDE) highlight a block of text, grab the text and move it, pick it up and drop it.

Move away from the window and the bug is triggered.
Comment 9 Daniel Rowe 2017-01-17 07:53:26 UTC
Also to note closing the intelliJ based IDE also unblocks the inputs.
Comment 10 Olivier Fourdan 2017-01-19 13:50:30 UTC
From comment 8, I wonder if this could be related to DnD code in mutter, does the same occur with another Wayland compositor such as weston?
Comment 11 Daniel Rowe 2017-01-21 01:43:30 UTC
Under weston I can't actually drag text.

I hight light text, but can't drag it, just get a circle with a line through it.
Comment 12 Krishnan 2017-01-29 03:22:13 UTC
Created attachment 129206 [details]
Error log generated by Android Studio which is based on IntelliJ Idea.

This is the error log auto-generated by Android Studio which is also based on IntelliJ Idea. Android Studio crashes when clicked on color preview near to line numbers in any xml file to open color picker. And it auto-generates this java error log file for each crash.
Comment 13 Kevin Wittek 2017-02-10 23:47:37 UTC
(In reply to Daniel Rowe from comment #8)
> I have worked out what it is and are able to get it to do it 100% of the
> time.
> 
> In PyCharm (or any intelliJ based IDE) highlight a block of text, grab the
> text and move it, pick it up and drop it.
> 
> Move away from the window and the bug is triggered.

I can trigger the same bug using IntelliJ IDEA 2016.3.3, libinput.x86_64 1.6.0-2.fc25
Comment 14 Tassilo Horn 2017-03-09 15:49:47 UTC
In the IntelliJ bug report, there's at least one user who has the problem with X11, too.  He suggests that the common denominator could be that we are all using an Intel graphics chip and the Intel graphics driver.

At least for me, that would also fit the bill, although I can't remember having this issue before switching to Gnome on Wayland sessions.
Comment 16 Olivier Fourdan 2017-03-10 08:08:05 UTC
Closing as "not out bug" (in Xwayland), this is mutter which should now be addressed in mutter.
Comment 17 Olivier Fourdan 2017-03-10 08:10:47 UTC
Note wrt comment 14, there might be other issues with IntelliJ on X11 but those are unrelated, and unlikely to be caused by the intel driver.


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.