Bug 502084 - The cursor can't reach the first row of pixels of maximized windows if the auto-hide panel is there
Summary: The cursor can't reach the first row of pixels of maximized windows if the au...
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (other bugs)
Version First Reported In: 6.3.3
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland-only
Depends on:
Blocks:
 
Reported: 2025-03-27 18:10 UTC by Fernando M. Muniz
Modified: 2025-08-21 06:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
It happens on non-maximized windows too. (1.93 MB, video/x-matroska)
2025-03-27 19:05 UTC, Fernando M. Muniz
Details
Soft-Locked a window out of screen due to the Schrödinger Pixel. (2.73 MB, video/mp4)
2025-03-28 23:47 UTC, Fernando M. Muniz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fernando M. Muniz 2025-03-27 18:10:35 UTC
1- Have a vertical auto-hide panel on the left of the screen
2- Have a maximized window, like Dolphin.
3- Move the cursor as far to the left as possible without causing the panel to appear.

Result:
You can see the left outline of the cursor (1 pixel wide), meaning that that row of pixels can't be clicked.

Expected Results:
You should not be able to the left outline of the cursor (just like you don't when the panel is open), allowing you to click on that area.


OBS: This can also be observed on flatpaks apps after the very recent "Wayland Cursor Shape Protocol" update.
https://bugs.kde.org/show_bug.cgi?id=498513#c6
Comment 1 Fernando M. Muniz 2025-03-27 19:05:43 UTC
Created attachment 179792 [details]
It happens on non-maximized windows too.
Comment 2 Nate Graham 2025-03-28 20:26:36 UTC
So your complaint is that the cursor can't reach the left-most pixel until the auto-hide panel opens? I can reproduce that too, but is there any indication that this is a problem? Is it causing you any issues in actual usage of the system?
Comment 3 Fernando M. Muniz 2025-03-28 23:22:36 UTC
I think I found one just now: If you un-maximize a window and by default its left border is on that vertical row of pixels, you can't drag and resize without pulling the window out by its title bar.

I thought I had something more when trying to drag and pull the YouTube sidebar while playing a video, but its hitbox is a lot of pixels wide.
Comment 4 Fernando M. Muniz 2025-03-28 23:47:44 UTC
Created attachment 179833 [details]
Soft-Locked a window out of screen due to the Schrödinger Pixel.

1- Have the panel with auto-hide at the inferior side of the screen horizontally.
2- Shove a window on the left corner and reduce the right side of the window until its framing is right on the Schrödinger Pixel.
3- Move the Panel to the left corner vertically.

Result:
You can't drag the window, it's soft-locked on the Schrödinger Pixel.
Comment 5 Nate Graham 2025-03-31 16:19:06 UTC
Maybe don't do that. :) 

In principle when there's an auto-hide panel on a screen edge, the pixels of that screen edge are used to make it appear. Therefore anything else you put on those pixels is going to be hard or impossible to reach.

I'm struggling to think of a way to improve this situation. At a certain point I think you need to take responsibility for your own configuration of the system, and not set it up in a way where different elements of it are incompatible and interfere with one another.
Comment 6 Fernando M. Muniz 2025-03-31 16:23:18 UTC
The panel while retracted needs a tangible 1 pixel wide hitbox?
I thought that the actual condition for opening was to hover in its direction for a set amount of frames.
Comment 7 Nate Graham 2025-03-31 16:25:59 UTC
The 1px hitbox is what provides that hover handling, yes. :)