SUMMARY Since the last update (see below for specifics), the area in which the user can click to initiate window resizing has significantly shrunk on the top area of said windows. In fact, you have to be almost perfectly pixel-aligned with the window border in order to resize windows from there. This is not just inconvenient to able-bodied users, but also a significant accessibility issue for disabled users. STEPS TO REPRODUCE 1. Open any window 2. Move the cursor to the top left or top right corner to resize it OBSERVED RESULT You have to be very precise in moving the mouse cursor so that it aligns to the window border. EXPECTED RESULT The top area behaves like the bottom one, which still accepts input a few pixels away from the window. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION
Is this on X11, or Wayland, or both?
What decoration theme do you use?
I've tested this on X11. The decoration theme is Breeze.
Can you try on Wayland too?
So, I've tried with other decorations and it's the same with all of them. It also happens on Wayland on a different computer.
Thanks for testing!
I can reproduce this behavior on my Fedora KDE 42 device, with Breeze window decorations in a Wayland session. At first, I wondered if this was somehow intentional behavior, to try to avoid the top edge of one window interfering with access to an adjacent window's controls, or with a top-aligned panel? I don't recall seeing anything related to that going into effect in 6.3.5, though. Thanks!
Created attachment 181484 [details] Resize arrow triggering at different distances from the top border vs. other borders
I moved this bug report to Breeze because Kwin has nothing to do with it. Breeze disables the top resize border https://invent.kde.org/plasma/breeze/-/blob/7f9ec509a3ef8a53ba265f32b39c8cc832fea787/kdecoration/breezedecoration.cpp#L482
Not sure if it's actually a bug though. I assume that breeze doesn't set that resize border because there's some space reserved by the decoration on top.
(In reply to Vlad Zahorodnii from comment #9) > I moved this bug report to Breeze because Kwin has nothing to do with it. > Breeze disables the top resize border > https://invent.kde.org/plasma/breeze/-/blob/ > 7f9ec509a3ef8a53ba265f32b39c8cc832fea787/kdecoration/breezedecoration. > cpp#L482 It's not just Breeze, though. Every single window decoration I have tried does this: Oxygen, Arc, Plastik, Qogir, all exhibit the same behaviour.
Why is the outside-of-the-window resize clickable area left up to the window anyway? Couldn't the compositor pick up clicks in that area, and e.g. clamp them to the window area to make sure the resize works no matter if the theme is aware of "invisible outside areas for resize" or not?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/breeze/-/merge_requests/582
I added the same margin at the top and did not notice any problems during testing. https://invent.kde.org/plasma/breeze/-/merge_requests/582 According to the history of GIT, I found that this functionality with 'resize' borders seems to have been added in 2014 (https://invent.kde.org/plasma/breeze/-/commit/e88463c09c0d042ed043afa1470fcb6bcd0664b4) But there is no explanation why the top margin is zero. There may have been some problems before, but I haven't found any problems now. I've tested this change on Breeze Qt6 + KDE 6, Breeze Qt5 + KDE 5, X11, and Wayland.
Created attachment 189438 [details] Resize arrow triggering after MR 582 (add top margin)
Since that's a breeze commit, I'm guessing this isn't some compositor level fix to make sure this works no matter the theme?
(In reply to Ellie from comment #16) > Since that's a breeze commit, I'm guessing this isn't some compositor level > fix to make sure this works no matter the theme? That's right, this MR 582 adds a top margin only for Breeze decoration by adding a top border in 'resizeOnlyBorders'. But the 'resizeOnlyBorders' feature itself comes from the kwin compositor. It's just that at the level of the decoration theme we can control the width of these invisible borders, and transfer the width values of the invisible borders for all four sides to kdecoration -> kwin. I also think the idea here is that when we have the visible window borders enabled, usually the invisible borders ('resizeOnlyBorders') are not used, and the window can only be resized by dragging these visible window frames. It is probably for these reasons that invisible borders are managed at the decoration theme level, rather than globally at the compositor level. So, in my opinion, it would be wrong to hardcode these borders at the kwin level.