Summary: | KWin inappropriately allows SSD windows to be resized to a width of 0 | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | pietz |
Component: | decorations | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | kde, nate, postix, putr4.s, xaver.hugl |
Priority: | HI | ||
Version: | 5.27.4 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/0900264e6f538ff915186b1bd9e528e568b28c1d | Version Fixed In: | 6.0 |
Sentry Crash Report: |
Description
pietz
2023-05-01 14:52:15 UTC
This would be a libreoffice bug and needs reporting there, sorry. I disagree! Sure, it may be a fault of libre office and can be fixed there. But it is a really BIG problem if a window manager will let you shrink a window to this tiny space to be unmovable anymore. KWin should protect the user from "bad apps", shouldn't it? It is not always the best way to point only to others when problems appear :-) KWin can't known what a sensible minimum size for app content should be; it simply doesn't have enough information. However KWin can at least prevent you from resizing the widow to have a width of 0, since this cuts off content that KWin itself renders on the titlebar. KWin already prevents the window from having a height of less than the titlebar height, for the same reason. So it could conceivably grow the ability to prevent the window width from being less than the width of the titlebar buttons. so they're always accessible. Beyond that, I agree with David that it's up to the window itself to set a sane minimum size, and this will be even more true for CSD windows where KWin doesn't draw a titlebar. At least a window manager should NEVER resize a window smaller than its window buttons bar, right? In my case all buttons (like close, pin, maximize, ...) are invisible and inaccessible. Okay, and when there is no title bar at all (borderless), it should be up to the inner app. This bug is gone at least with LibreOffice, when I upgraded to Kubuntu 23.04. I don't know if the fix was made by KWin (good) or by LibreOffice. In the last case, the bug my be still produce problems on other UI apps that allow a minimumSize of zero... (In reply to pietz from comment #5) > This bug is gone at least with LibreOffice, when I upgraded to Kubuntu > 23.04. I don't know if the fix was made by KWin (good) or by LibreOffice. In > the last case, the bug my be still produce problems on other UI apps that > allow a minimumSize of zero... Sorry, I was wrong in this last post. It still happens with LibreOffice when you are in a Writer document. It just doesn't happen when LibreOffice shows the "greeting window"! Yeah, I can confirm it's still an issue with LibreOffice 7.5.3.0. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4360 > I don't know if the fix was made by KWin (good) or by LibreOffice
LibreOffice definitely should set reasonable minimum size hints. Not setting min size for an app such as LibreOffice can be considered as a bug. Please report this issue to LO developers too.
Sure. Every application SHOULD set minimum sizes. But it is also an important job for a window manager to avoid resizing a window to a zero-size where you can never "find" your window again. (In reply to Vlad Zahorodnii from comment #9) > Please report this issue to LO developers too. Upstream bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=156935 Having KWin be able to prevent cases like this can also be useful when there's a bug somewhere in the stack where the app gets accidentally resized to zero (instead of just the user doing that by accident), in my case I've had a few occurrences where I tried to tile a LibreOffice window or two to the corners of the screen (or also untiling it I think) and one of them decides to resize to zero instead, forcing me to close said window via the task manager. Of course ideally such bugs should be fixed directly, but I've yet to be able to find even a somewhat consistent reproducer since so far it has always happened when I don't have the time to play around and figure out what exactly I did to cause it. (In reply to postix from comment #11) > (In reply to Vlad Zahorodnii from comment #9) > > Please report this issue to LO developers too. > Upstream bug report: > https://bugs.documentfoundation.org/show_bug.cgi?id=156935 FWIW: This bug has already been known to LO for more than 7 years ... https://bugs.documentfoundation.org/show_bug.cgi?id=97894 Git commit 28c27609a4b45cf08b53dcc7dfe90f23c3338797 by Xaver Hugl. Committed on 06/11/2023 at 15:55. Pushed by zamundaaa into branch 'master'. xdgshellwindow: enforce a minimum size for clients It doesn't make sense for a window to become 1x1 pixels small. When we have server side decorations we also know that the decoration takes a lot of space, so this commit enforces a bigger minimum size for decorated windows M +4 -4 autotests/integration/xdgshellwindow_test.cpp M +2 -1 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/28c27609a4b45cf08b53dcc7dfe90f23c3338797 Git commit 0900264e6f538ff915186b1bd9e528e568b28c1d by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 08/11/2023 at 10:55. Pushed by vladz into branch 'Plasma/5.27'. xdgshellwindow: enforce a minimum size for clients It doesn't make sense for a window to become 1x1 pixels small. When we have server side decorations we also know that the decoration takes a lot of space, so this commit enforces a bigger minimum size for decorated windows (cherry picked from commit 28c27609a4b45cf08b53dcc7dfe90f23c3338797) M +4 -4 autotests/integration/xdgshellwindow_test.cpp M +2 -1 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/0900264e6f538ff915186b1bd9e528e568b28c1d |