Bug 442682 - Text Labels eat all wacom tablet input
Summary: Text Labels eat all wacom tablet input
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-qqc2-desktop-style
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.86.0
Platform: Kubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-19 08:37 UTC by 2155X
Modified: 2021-09-23 12:54 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Video showing the problem on haruna (1.75 MB, video/webm)
2021-09-19 08:37 UTC, 2155X
Details
Video showing the problem on plasma-systemmonitor (2.00 MB, video/webm)
2021-09-19 08:37 UTC, 2155X
Details
Video showing the problem on discover (551.61 KB, video/webm)
2021-09-20 09:49 UTC, 2155X
Details
haruna on 5.80.0 (1.39 MB, video/webm)
2021-09-22 07:07 UTC, 2155X
Details
haruna on 5.86.0 (1.61 MB, video/webm)
2021-09-22 07:08 UTC, 2155X
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 2155X 2021-09-19 08:37:23 UTC
Created attachment 141694 [details]
Video showing the problem on haruna

SUMMARY
Hovering over certain text elements with a graphics tablet causes input to be eaten. Clicks are ignored and hover highlighting does not show up. Hover event gets stuck until I click away somewhere else. 
MenuBar is also affected, causing usage of certain applications to become very difficult.
The only way to use such elements is to hover only over the part which has no text. Usually a few pixels above and below the text element.

STEPS TO REPRODUCE
1. Start a KDE application like haruna, plasma-systemmonitor
2. Find a ListModel with ListElements (MenuBar, GridLayout have the same issue)
3. Hover over the elements with a graphics tablet pen. 

OBSERVED RESULT
Hovering over the elements text causes input to be eaten and get stuck until you click away elsewhere. Clicking on the label does not work and you have to click on a corner without text in it.

EXPECTED RESULT
Hovering over the element should work correctly, it should get selected and be clickable.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 21.04, 5.11.0-35-generic
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0 (5.85.0 as well)
Qt Version: 5.15.2

ADDITIONAL INFORMATION
This problem does not exist in 5.80.0
Attached WEBMs of multiple applications to show the problem.
Comment 1 2155X 2021-09-19 08:37:48 UTC
Created attachment 141695 [details]
Video showing the problem on plasma-systemmonitor
Comment 2 2155X 2021-09-20 09:49:31 UTC
Sorry, I don't know how to edit the main post.

Looks like Discover is also affected by the issue. I have attached a video showcasing the problem with it as well.

Strangely, the items at the top: "Applications", "Application Addons" etc. are not affected.
Hovering over icons is not a problem as well.
Comment 3 2155X 2021-09-20 09:49:51 UTC
Created attachment 141724 [details]
Video showing the problem on discover
Comment 4 Nate Graham 2021-09-21 23:29:54 UTC
Cannot reproduce with the stylus and my laptop's touchscreen, but I might not be understanding the issue. The videos aren't much help, I'm afraid, because I can't see what your hands are doing.

Can you come up with a simpler to reproduce text case in one app, and describe it as clearly as possible? Like, to a baby lol
Comment 5 2155X 2021-09-22 07:07:33 UTC
Sorry for not being clear enough. I have made some new steps to reproduce and created comparison videos with 5.80.0 and 5.86.0. For the example I will be using haruna since it seems to be very broken because of this bug.

Steps to reproduce (installation):
1. Boot up a Kubuntu 21.04 Live USB
2. Install the Kubuntu-backports or Kubuntu-beta PPA via apt to get plasma-frameworks 5.86.0
3. Install haruna via apt

Steps to reproduce (menu bar):
1. Start haruna
2. Hover over the menu bar (one with "File", "View", "Playback" etc. buttons) and observe how they are not getting the hover color, hover status getting stuck, are unclickable, if your cursor was touching one of the buttons text fields
3. Click off to the side of the menu bar, with no items. Observe how this fixes the hover status getting stuck

Steps to reproduce (Settings->Configure):
1. Start haruna
2. Click Settings and Configure in the menu bar
3. Hover over the list of elements on the left side of the window (one with "General", "Playback", "Video" etc. buttons) and observe how they are not getting the hover color, get stuck, are unclickable, if your cursor touched the text field in any of those buttons and.
4. Once again, clicking off to the side of the app without text fields, should fix the hover status getting locked.

Steps to reproduce (Settings->Configure->Color Scheme):
1. Start haruna
2. Click Settings and Configure in the menu bar
3. Select the General tab on the left side
4. Open the Color Scheme selector
5. Hover over the elements and observe how they are not getting highlighted and are unclickable if you hover over the text.
Comment 6 2155X 2021-09-22 07:07:53 UTC
Created attachment 141783 [details]
haruna on 5.80.0
Comment 7 2155X 2021-09-22 07:08:07 UTC
Created attachment 141784 [details]
haruna on 5.86.0
Comment 8 Nate Graham 2021-09-22 16:40:53 UTC
Thanks, that helps. Unfortunately I cannot test Haruna right now as is it not packaged by my distro, and it crashes on launch with weird symbol errors when I built it from source, and I don't have time to investigate that right now. However I can reproduce the issue with the hover highlight effect not appearing for list views, as in System Monitor.

Can yo confirm that the only update was frameworks, such that we know this regression was introduced somewhere between Frameworks 5.80 and 5.85? Or were other parts of the system updated too? Because at this point I suspect there may be a general widespread Qt regression.
Comment 9 2155X 2021-09-22 16:54:37 UTC
Thank you for looking into this. Unfortunately I can't test individual packages/versions because I can't get them to build properly.

The only possibly related issue I found is QTBUG-95357: https://bugreports.qt.io/browse/QTBUG-95357

The bug does match with the tested frameworks 5.85.0, 8.86.0 using Qt 5.15.2
Frameworks 5.80.0, where it works fine, uses Qt 5.14.0

Is there a specific package I may be able to rebuild with Qt 5.14.0 that would temporarily work around this issue?
Comment 10 Nate Graham 2021-09-22 20:18:21 UTC
Ah, then in that case I would suggest it's Qt rather than anything in our code. I checked and nothing relevant to this has visibly changed between those frameworks versions. And  I actually just filed a somewhat similar bug on Qt recently for Radio Buttons with stylus input: https://bugreports.qt.io/browse/QTBUG-96782. It could have the same root cause as this bug. Could you file a new Qt bug for this? You could mention the one I filed to relate them.
Comment 11 2155X 2021-09-23 00:12:22 UTC
I have possibly located the source of the issue, it indeed looks like a bug from Qt. Comparing versions 5.14.0 to 5.15.2 led me to the solution:

in file: qtdeclarative/src/quick/items/qquickwindow.cpp
in function: QQuickWindow::tabletEvent

line (2256): d->deliverPointerEvent(d->pointerEventInstance(event));

Removing that line seems to solve all of the issues I have described.
From what I see, deliverPointerEvent is not fully implemented for tablet events yet and does not process them.

I will file a bug on the Qt tracker tomorrow.
Comment 12 Nate Graham 2021-09-23 03:11:37 UTC
Nice work finding the issue!!!
Comment 13 2155X 2021-09-23 09:41:45 UTC
I have created the bug report on the Qt tracker.
Feel free to follow it: https://bugreports.qt.io/browse/QTBUG-96839

Thank you again for looking into this and assisting me in figuring out what the problem is.
Comment 14 Nate Graham 2021-09-23 12:54:16 UTC
You're welcome!