Bug 392799 - Window contents also scroll while using alt + scroll wheel to change opacity
Summary: Window contents also scroll while using alt + scroll wheel to change opacity
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.12.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-06 13:00 UTC by Kishore Gopalakrishnan
Modified: 2018-04-08 04:55 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kishore Gopalakrishnan 2018-04-06 13:00:34 UTC
If we press 'alt' and scroll with the mouse wheel, kwin changes the opacity of the window under the mouse. However, scroll events are also passed to the window, and thus the window contents also scroll.

Steps to reproduce:
1. Open a window in which scrolling is possible (for eg. a long text file in kate or a webpage in a browser).

2. Press alt and scroll down with the mouse wheel.

Observed result:
The opacity decreases, and the window contents scroll down.

Expected result:
The opacity should change, but the window contents should not scroll.

This bug seems possibly related to bug 368827, but I am reporting it separately since it involves mouse events.
Comment 1 Martin Flöser 2018-04-06 14:03:15 UTC
Is this on X11 or Wayland?
Comment 2 Kishore Gopalakrishnan 2018-04-06 14:14:27 UTC
(In reply to Martin Flöser from comment #1)
> Is this on X11 or Wayland?

This is on X11. I haven't tested on Wayland.
Comment 3 Martin Flöser 2018-04-06 15:12:11 UTC
The reason for this problem is that KWin does not support xinput scrolling, but the application use xinput. KWin only grabs the mouse button, but not xinput. As KWin is feature frozen for X11 we cannot add support for xinput scrolling. To a certain degree this is also an application bug as they accept mouse events although another application has a mouse grab.
Comment 4 Kishore Gopalakrishnan 2018-04-07 00:58:48 UTC
(In reply to Martin Flöser from comment #3)
> To a certain degree this is also an application bug as they
> accept mouse events although another application has a mouse grab.

This seems to happen in all QT5 applications. However it doesn't seem to happen in GTK applications (I tested with GIMP). Should I report a QT bug?
Comment 5 Martin Flöser 2018-04-07 04:56:54 UTC
Please test a gtk-3 application instead of Gimp. If you cannot reproduce there it should be reported to Qt.
Comment 6 Kishore Gopalakrishnan 2018-04-08 01:10:54 UTC
(In reply to Martin Flöser from comment #5)
> Please test a gtk-3 application instead of Gimp. If you cannot reproduce
> there it should be reported to Qt.

I cannot reproduce this with gedit. 

Is it alright if I just report the bug to Qt as 'Qt applications accept mouse events although another application has a mouse grab', or is there some other relevant information I would need to give them for this bug?
Comment 7 Martin Flöser 2018-04-08 04:55:28 UTC
Best describe the complete situation and also that gtk-3 doesn't have this problem