| Summary: | asynchronous motif hint reading (maybe others) is broken. fetch() from events.cpp deletes m_hints, causing a (false) shortcut return for the tested function | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Soukyuu <chrno-sphered> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | d_tassos, lee295012, walmartshopper |
| Priority: | NOR | Flags: | thomas.luebking:
ReviewRequest+
|
| Version: | 5.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| URL: | https://git.reviewboard.kde.org/r/125007/ | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=246442 | ||
| Latest Commit: | http://commits.kde.org/kwin/cc6886d7dd91ab7a4206ae6637886d7664127bb9 | Version Fixed In: | 5.4.2 |
| Sentry Crash Report: | |||
| Attachments: |
xprop for the main foobar window
xprop for a second dialog window opened by foobar2000 kwin support information Picture showing the disappearance of the close button in Notepad++ under wine. Some thing happens to FreeFileSync as well. |
||
|
Description
Soukyuu
2015-05-16 23:07:26 UTC
please attach the ouputs of a) "qdbus org.kde.KWin /KWin supportInformation" b) "xprop" of such window that lost it's close button Sounds familiar, btw. https://bugs.kde.org/show_bug.cgi?id=246442 Created attachment 92669 [details]
xprop for the main foobar window
Created attachment 92670 [details]
xprop for a second dialog window opened by foobar2000
Created attachment 92671 [details]
kwin support information
dev note: MWM says the windows are closeable and they participate in _NET_WM_ACTION_CLOSE Breeze deco, hugo wired up closeableChanged for 5.2 @Soukyuu Did both windows have no closebutton when you took the xprop or only the main window? Both windows did not have a close button, correct. Basically main window opens converter window, which opens a folder select dialog. Once the folder select dialog is opened, both main and converter windows lose the close button. I can add an xprop of the folder select dialog window with a close button present, if you'd like me to. I can confirm this as well. I reported this quite some time ago, but i have no idea what happened to that report, can't find it by searching. I am using Notepad++ with wine and if you open a dialog box, eg save as... you will loose the close button, you don't need to save anything, just opening the dialog box is enough. However, this is also happening to FreeFileSync as well which is not running under wine. If you do a sync a new window pops up to show the sync process, after that the close button on the main application window has disappeared. You can still close a window by double clicking the menu button if that function is activated... Created attachment 94298 [details]
Picture showing the disappearance of the close button in Notepad++ under wine. Some thing happens to FreeFileSync as well.
The bug itself is far more general. Interestingly, wine triggers it because it feels like it has to remove the close button for a window that is blocked by a modal transient. (I wonder whether we should ignore that hint as well - every window should be closable and we know how to handle modal states...) Git commit cc6886d7dd91ab7a4206ae6637886d7664127bb9 by Thomas Lübking. Committed on 14/09/2015 at 19:01. Pushed by luebking into branch 'Plasma/5.4'. fetch motif hints when get them for managed client notably *after* storing the old values. Otherwise the old value is polluted because of m_hints being nullptr, thus a default value is returned (instead of the actual old value) FIXED-IN: 5.4.2 REVIEW: 125007 M +2 -0 client.cpp M +0 -1 events.cpp http://commits.kde.org/kwin/cc6886d7dd91ab7a4206ae6637886d7664127bb9 |