Summary: | kwin crashes when using the Mazimize button on all non-standard window decorations with BorderlessMaximizedWindows=true | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Hjorten <hjorten.misc> |
Component: | aurorae | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | Keywords: | drkonqi |
Priority: | NOR | Flags: | mgraesslin:
ReviewRequest+
|
Version: | 5.5.4 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
URL: | https://phabricator.kde.org/D1586 | ||
Latest Commit: | http://commits.kde.org/kwin/6cd0d5a54acf618d094097b6222f331352abe7b0 | Version Fixed In: | 5.6.5 |
Description
Hjorten
2016-05-07 08:01:14 UTC
*** Bug 362770 has been marked as a duplicate of this bug. *** This is like bug #346857 and is https://bugreports.qt.io/browse/QTBUG-48921 Bug #346857 works around the problem when closing a window, but not when maximizing it (because the issue won't occur unless the deco is destroyed by the maximization as in your setup) Worst of all is that this is also related to bug #303450 (QGraphicsScene cannot cut events and by this crash itself ...), so I guess this will never be fixed in Qt (because applications aren't destroyed on smartphones ...) => A similar workaround in the aurorae decoration will be required if one wants to remain with QML. Thanks for the explaination. To me it seemed strange that Kwin does NOT crash, if I choose "Maximize" by right clicking on the process' icon in the task bar, nor does it crash if I choose Maximize from the Window menu (invoke by right-clicking the application icon of the window, or alt-f3). So will it be fixed in aurorae at some point? (In reply to Hjorten from comment #3) > To me it seemed strange that Kwin does NOT crash, if I choose "Maximize" by > right clicking on the process' icon in the task bar, nor does it crash if I > choose Maximize from the Window menu No, that perfectly fits the pattern. QML tries to process the event in an object that was destroyed by the event (and that is not event interceptable) > So will it be fixed in aurorae at some point? Can't - the bug is in QML. The aurorae decoration could work around the problem by delaying the (potentially) destructive action by one event cycle just like it does for closing. No idea whether it will, I simply stopped using Qt/KDE. (In reply to Thomas Lübking from comment #4) > (In reply to Hjorten from comment #3) > > The aurorae decoration could work around the problem by delaying the > (potentially) destructive action by one event cycle just like it does for > closing. No idea whether it will, I simply stopped using Qt/KDE. I would have assumed you were a KDE developer(?). But is what you are saying, that you are not anymore? ("I simply stopped usingQt/KDE") How about that this is also about a KDE bug, even if it originate from QT, even though KDE/Plasma could potentially apply a work-around? So should people abandon KDE (which is by nature built-upon QT)? because the developers are not using it anymore? Or did I get that wrong too? I *was* a user for 15 and developer for 10 years, but looking at state, development an apparent direction of Qt5 for several years now, took the *personal* decision to better not rely on it anymore. What other people should do, other people need to figure themselves. There're still KDE developers around and KWin is still maintained (if that's your worries) I'm just triaging bugs for a few months as last service, because my knowledge didn't immediately drop out of my head. Not sure about your middle paragraph, but this is a design bug/flaw in QtQuick that client code can seek to avoid (by forementioned workaround) but not fix. Problem reproduced with a test case and fix in https://phabricator.kde.org/D1586 Git commit 6cd0d5a54acf618d094097b6222f331352abe7b0 by Martin Gräßlin. Committed on 11/05/2016 at 11:45. Pushed by graesslin into branch 'Plasma/5.6'. Delay maximize button click to next event cycle Summary: The delay to next cycle dance is needed for Aurorae. Maximizing a window can result in the decoration being destroyed, in which case QtQuick can trigger a crash. A test case is added to simulate the situation and ensure that maximize still works also after the change. FIXED-IN: 5.6.5 Reviewers: #plasma Subscribers: plasma-devel Projects: #plasma Differential Revision: https://phabricator.kde.org/D1586 M +11 -0 autotests/wayland/CMakeLists.txt A +155 -0 autotests/wayland/dont_crash_aurorae_destroy_deco.cpp [License: GPL (v2)] M +1 -0 clients/aurorae/themes/plastik/package/contents/ui/main.qml M +6 -1 decorations/decoratedclient.cpp M +4 -0 decorations/decoratedclient.h http://commits.kde.org/kwin/6cd0d5a54acf618d094097b6222f331352abe7b0 |