Kubuntu 17.10, Plasma & kwin 5.11.4 After using the Kubuntu Backports PPA to upgrade my machine from 5.9.5 to 5.11.4, for my user account, every window titlebar's top-right-most pixel no longer triggers the close button. In 5.9.5 the titlebar's top-right-most pixel did trigger the close button, allowing me to close a maximized or right-tiled window by flinging my cursor into the top-right corner and clicking. REPRODUCIBILITY With my user on Kubuntu 17.10 with Plasma and kwin 5.11.4: - Can reproduce - Can reproduce when using Breeze and Plastik window decoration styles - Can reproduce when the titlebars are taller or shorter than normal due to larger or smaller font size chosen for titlebar text - Can reproduce for all windows - Can reproduce after reboot - Can reproduce after removing existing kwinrc and breezerc files With a new user on the same machine: - Cannot reproduce With the existing user on my KDE Neon (dev unstable) VM on 5.11.4: - Cannot reproduce With a new user on my KDE Neon (dev unstable) VM on 5.11.4: - Cannot reproduce I am tearing out my hair because I cannot figure out what is different about my user account on this machine that triggered the issue to appear on upgrade, and I have not been successful in getting the issue to go away.
Please use xprop and xwininfo on the top right corner. It should print the window which takes the click.
Created attachment 109237 [details] xprop on the screen's top-right-most pixel when Firefox is maximized
Created attachment 109238 [details] xwininfo on the screen's top-right-most pixel when Firefox is maximized Attached. The correct window gets the click, it's just that the click doesn't trigger the right-most titlebar button (in this case the close button) the way it used to.
I'll mention that this issue reproduces on X11 and also Wayland.
Please provide output of qdbus org.kde.KWin /KWin supportInformation
Created attachment 109244 [details] kwin support information
I'm sorry, but I'm also out of ideas. The only idea I have is that somehow your input events are of by a pixel. That's something you could check with xev or KWin debug console on Wayland.
Created attachment 109246 [details] Screen recording of the issue Come to think of it, it's actually not a one-pixel problem; there's a rather large dead zone. I'm uploading a screen recording that shows the issue. Also, this doesn't reproduce with a new user account. Seems unlike to be an input issue. I'm using a 48-pt cursor, but it reproduces using the standard cursor size.
Do you have touch screen edges activated?
No.
Created attachment 109280 [details] Problem occurs when "Draw window borders for maximized windows" is checked Found the issue. you can perfectly reproduce it by turning on System Settings > Application Style > Window Decorations > Breeze > Configure > "Draw window borders for maximized windows". With that setting checked, the click zone for the right-most button seems to shrink. It isn't just that the border relocates the click zone; the click zone actually shrinks. You can see this by changing your window borders to No Borders; the titlebar buttons don't move, but the click zone shrinks. I'm attaching a video that shows the exact issue. Also it doesn't make sense to have this option even available with No Borders (there are no borders to draw!), but that's a separate issue.
Created attachment 109281 [details] The issue with borders turned on Video showing the issue with window borders set to something other than No Borders
Not a bug, sorry. (and the title is wrong). When "draw Window borders for maximized windows" is selected, there is no more differences (from the deco point of view) between a maximized and a not maximized window. And the buttons have the _same_ hit area in both cases. This so that one can resize the window from its borders. only when the option is unchecked does a maximized window behave differently from an unmaximized one: you cannot resize the window from its borders, and the hit area for the buttons is _expanded_. I think this is the natural behavior that one would expect from the deco (and that all decorations behave the same). Closing as invalid. (As for: there should be now option when "no border" is selected, the point is that in fact, even in the "no border" case, the 'top' border, from which you can resize the window, is always drawn.)
Thanks Hugo. Could we consider changing the string to indicate that it will make the window resizable while maximized? That might help explain the purpose of the feature (i.e *why* you might want the window borders to be shown when the window is maximized). How about this: "Draw window borders and allow resizing for maximized windows" If that (or something else) seems reasonable, I'd be happy to submit a patch for it.
Git commit bdf85c5c32f6a0eb3ea5f56b8008f4ed16fba424 by Nathaniel Graham. Committed on 12/12/2017 at 13:23. Pushed by ngraham into branch 'master'. Make it obvious what "Display window borders for maximized windows" is for Summary: Change "Display window borders for maximized windows" to "Allow resizing maximized windows from window esges" This makes it obvious what the purpose of the feature is, and why one would want to turn it on. Test Plan: Tested in KDE Neon. feature still works, and only the text is changed. Before: {F5540181} After: {F5542554} Reviewers: hpereiradacosta, #breeze, #vdg Reviewed By: hpereiradacosta Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D9284 M +1 -1 kdecoration/config/ui/breezeconfigurationui.ui https://commits.kde.org/breeze/bdf85c5c32f6a0eb3ea5f56b8008f4ed16fba424