Created attachment 162741 [details] Window placed at the top of the screen, floating panel shown on top. SUMMARY Following panel configuration: - floating - auto-hidden - at the top edge of the screen The panel should allow grabbing maximized window at the upper edge, for reszing for example. As the panel is floating, the visuals suggest that there would be some pixels "free space" to be able to grab the window at the title bar. But, actually the mouse focuses on the panel, when pointer is hovered on this free space above the panel. STEPS TO REPRODUCE 1. Make panel floating, auto-hidden and place it to the top of the screen 2. Move a window to the top of the screen, or maximise it 3. Move mouse to the top of the screen to have panel shown 4. Click and hold on the free space above panel to grab the window OBSERVED RESULT Panel action at the location below the mouse pointer tip is started (e.g. a taskbar item) EXPECTED RESULT The window is grabbed at the title bar, to be able to move or resize, since the panel is not coverig the window at this position. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231028 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.5.9-1-default (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15,5 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B79 System Version: 4.0
Hi! This is actually intentional. The panel grabs the mouse input of events between the panel and the screen to make sure that Fitt's law is preserved (e.g. moving the mouse to the very border above an applet and clicking will still trigger that applet, similarly to when the panel is not floating).
(In reply to Niccolò Venerandi from comment #1) > Hi! This is actually intentional. The panel grabs the mouse input of events > between the panel and the screen to make sure that Fitt's law is preserved > (e.g. moving the mouse to the very border above an applet and clicking will > still trigger that applet, similarly to when the panel is not floating). I don't know Fitt's law, but visually this is quite counter-intuitive, as well as the behavior is a bit asymmetric: the panel gets hidden immediately when you move the pointer just outside the panel are (Meaning, you cannot interact with the panel when mouse pointer is just moved outside the visible panel). BUT: then as contrary. the pointer will interact with the panel elements, if the pointer is *above* the visible panel, but not pointing to the actual panel anymore. Also, auto-hide affects how the floating panel looks like. If auto-hide = off, then I as user would expect the mentioned behavior that pointing above the panel item would have a function; this is when the panel does not have a gap at the top. But, when auto-hide is off, there is a gap at the top of the screen, and it is quite weird that the mouse actyally points to the panel items (again, when moving the mouse pointer out below the panel, there is no "Fitts law margin", but the panel gets immediately hidden.)
Created attachment 162759 [details] Floating panel, auto-hide = on This image illustrates floating panel with auto-hide = on. There is a gap where mouse pointer very well fits, but instead of how this is visualized, the panel action item below the pointer gets activated.
Created attachment 162760 [details] Floating panel, auto-hide = off Floating panel with auto-hide = OFF. Here as a user I would more expect that the panel item is activated, as there is no visual gap between the panel and the top of the screen. So there is no windows or other UI items visually observed as being accessible just above the panel, as there is no vertical gap.
(In reply to Lassi Väätämöinen from comment #3) > Created attachment 162759 [details] > Floating panel, auto-hide = on > > This image illustrates floating panel with auto-hide = on. There is a gap > where mouse pointer very well fits, but instead of how this is visualized, > the panel action item below the pointer gets activated. Or if the gap is only a visual gimmick, I think the gap should be made so small that there is no possibility for a user to assume that the area below would be pointable.
It's intentional, sorry. There is no gap we can make small enough to avoid the visual gimmick. It either exists or not; nothing else make sense. If you don't like the floating style, you're welcome to disable it. Please don't re-open bug reports that developers have closed.