Bug 345634 - Panel steals mouse focus in full screen applications
Summary: Panel steals mouse focus in full screen applications
Status: RESOLVED DUPLICATE of bug 217560
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: 5.2.2
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-29 02:13 UTC by Stephen Kraemer
Modified: 2015-03-29 20:26 UTC (History)
1 user (show)

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 Stephen Kraemer 2015-03-29 02:13:16 UTC
So I'm not sure if my title correctly describes the problem I see, but basically, when I play DOTA2, with a panel on the left side of my desktop set to auto-hide, then DOTA2 doesn't properly respond to me moving my mouse to the left edge of the screen (it should scroll the map but doesn't). I also noticed that when entering the region on the left side of the screen that the panel would normally occupy, that my cursor changes from the in-game one to my typical desktop one. When I turned off auto-hide on my panel, I no longer saw this problem. I believe that the plasma desktop is stealing the mouse focus (or something) when I move to the left edge of the screen as it is trying to unhide the panel.

Reproducible: Always

Steps to Reproduce:
1. Create panel with autohide enabled
2. In fullscreen DOTA 2, in game move mouse to left side of the screen

Actual Results:  
The map should scroll but it doesn't - note that all other edges work fine. I am assuming that the panel auto-hide is stealing mouse notifications

Expected Results:  
Panel should not steal mouse notifications of fullscreen application
Comment 1 Thomas Lübking 2015-03-29 20:23:45 UTC
David, this is bug #217560 - KWin doesn't manage those proxies (on X11, wayland will be a whole different story) and hides its own when there's a(n active, i think) fullscreen window.

=> Do you have a special reason why you think kwin should handle this (and how)?

There's also https://git.reviewboard.kde.org/r/106110/ but IIRC, it's technically wrong.
Comment 2 Stephen Kraemer 2015-03-29 20:26:06 UTC
Looks like a duplicate of that bug to me. Sorry for the extra bug.
Comment 3 David Edmundson 2015-03-29 20:26:39 UTC

*** This bug has been marked as a duplicate of bug 217560 ***