| Summary: | window caption changes thrash tabbox stacking order | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Harald Sitter <sitter> |
| Component: | platform-x11-standalone | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | nate |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | kwinrulesrc | ||
Thank you for diagnosing the culprint of the bug. Do you know why the client is made first in the focus chain? I have very limited knowledge of the activities-related code and the feature itself. Can you also post your ~/.config/kwinrulesrc? (In reply to Vlad Zahorodnii from comment #1) > Thank you for diagnosing the culprint of the bug. Do you know why the client > is made first in the focus chain? I have very limited knowledge of the > activities-related code and the feature itself. Not really. I suspect it's for the case when the client is new rather than when a client changes. Like say I start dolphin on activity Foo and have a rule that also forces it on activity Bar (I'm not sure that's even how this feature would work) it'd need to be marked first in both for the focus chain in Bar to reflect the fact that it's a new client. Other than that I fail to imagine why it'd ever need to force a client to the front of the chain. Created attachment 130962 [details]
kwinrulesrc
From the attached kwinrulesrc file:
[3]
Description=Application settings for telegramdesktop
clientmachinematch=0
noborderrule=2
screen=0
wmclass=telegram-desktop telegramdesktop
wmclasscomplete=true
wmclassmatch=1
The window rules match only telegram-desktop telegramdesktop window class, so I don't really understand why kwin starts re-evaluating window rules when the caption changes.
I've added some debug output to Rules::match and it's the plymouth rule that causes the caption watching. All other rules would get discarded because of the earlier checks in ::match, plymouth doesn't so it falls into the (titlematch != UnimportantMatch) branch which then causes the connection to evaluateWindowRules and that then leads to the trace ending up in the focus chain change. Ugh. |
For the longest time I'm getting annoyed by the tab order of applications getting messed up so when I keep switching between my editor and a terminal at some point a random unrelated app will pop up. Turns out the stacking order gets thrashed by caption changes. STEPS TO REPRODUCE 1. use spotify client (as snap, though I doubt it matters) 2. setup a global shortcut for the 'media controller's next action 3. play a playlist in spotify 4. have a bunch of windows open make sure spotify is no where near the latest window 5. trigger next track 6. wait a bit 7. alt-tab once or twice OBSERVED RESULT The stack order in the tab will be off on the second alt-tab EXPECTED RESULT Stack order remains as it was ADDITIONAL INFORMATION What happens here is that as a new track is played spotify changes the caption which triggers a re-eval of the window rules and that calls X11Client::setOnActivities and that causes a FocusChain update. This is messed up in two ways even. a) it makes a window First that isn't actually, hence why on the first alt-tab things seem to be alright but on the second the previous window will be considered spotify even though it never was active at all b) obviously caption changes shouldn't mess with the stacking order *at all* ^^ This also happens a lot with the telegram client where unread messages are part of the caption. Backtrace below. I've also confirmed that entirely disabling the setOnActivities call fixes the problem. Supposed applyWindowRules and/or setOnActivites should only actually change anything iff there are changes needed? Although, even when a window is forced onto activities it shouldn't mess with the tab order of the active activity I guesss. Thread 1 "kwin_x11" hit Breakpoint 2, KWin::FocusChain::updateClientInChain (this=0x20a0ad0, client=0x2f0baf0, change=KWin::FocusChain::MakeFirst, chain=...) at ../focuschain.cpp:122 122 if (change == MakeFirst) { #0 KWin::FocusChain::updateClientInChain(KWin::AbstractClient*, KWin::FocusChain::Change, QList<KWin::AbstractClient*>&) (this=0x20a0ad0, client=0x2f0baf0, change=KWin::FocusChain::MakeFirst, chain=...) at ../focuschain.cpp:122 #1 0x00007f465be062e6 in KWin::FocusChain::update(KWin::AbstractClient*, KWin::FocusChain::Change) (this=0x20a0ad0, client=0x2f0baf0, change=KWin::FocusChain::MakeFirst) at ../focuschain.cpp:117 #2 0x00007f465bfaec59 in KWin::X11Client::updateActivities(bool) (this=0x2f0baf0, includeTransients=false) at ../x11client.cpp:1972 #3 0x00007f465bfaeb3d in KWin::X11Client::setOnActivities(QStringList) (this=0x2f0baf0, newActivitiesList=...) at ../x11client.cpp:1943 #4 0x00007f465beb2ee1 in KWin::AbstractClient::applyWindowRules() (this=0x2f0baf0) at ../rules.cpp:859 #5 0x00007f465bfbaadf in KWin::X11Client::applyWindowRules() (this=0x2f0baf0) at ../x11client.cpp:4992 #6 0x00007f465bd42f31 in KWin::AbstractClient::evaluateWindowRules() (this=0x2f0baf0) at ../abstract_client.cpp:2697 #7 0x00007f465bd508f4 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (KWin::AbstractClient::*)()>::call(void (KWin::AbstractClient::*)(), KWin::AbstractClient*, void**) (f=(void (KWin::AbstractClient::*)(KWin::AbstractClient * const)) 0x7f465bd42f00 <KWin::AbstractClient::evaluateWindowRules()>, o=0x2f0baf0, arg=0x32252b8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:152 #8 0x00007f465bd50858 in QtPrivate::FunctionPointer<void (KWin::AbstractClient::*)()>::call<QtPrivate::List<>, void>(void (KWin::AbstractClient::*)(), KWin::AbstractClient*, void**) (f=(void (KWin::AbstractClient::*)(KWin::AbstractClient * const)) 0x7f465bd42f00 <KWin::AbstractClient::evaluateWindowRules()>, o=0x2f0baf0, arg=0x32252b8) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:185 #9 0x00007f465bd50745 in QtPrivate::QSlotObject<void (KWin::AbstractClient::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x7f464c01dbe0, r=0x2f0baf0, a=0x32252b8, ret=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:418 #10 0x00007f4658ce42a9 in QObject::event(QEvent*) (this=0x2f0baf0, e=0x3225270) at kernel/qobject.cpp:1339 #11 0x00007f46597c8cc3 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #12 0x00007f46597d1f40 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #13 0x0000000000408abd in KWin::ApplicationX11::notify(QObject*, QEvent*) (this=0x7ffe3d30fea0, o=0x2f0baf0, e=0x3225270) at ../main_x11.cpp:278 #14 0x00007f4658cb678a in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x2f0baf0, event=0x3225270) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:153 #15 0x00007f4658cb8f74 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (receiver=0x0, event_type=0, data=0x1d855b0) at kernel/qcoreapplication.cpp:1815 #16 0x00007f4658d0c577 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x1e4a5f0, flags=...) at kernel/qeventdispatcher_unix.cpp:466 #17 0x00007f465444b8d2 in QXcbUnixEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x1e4a5f0, flags=...) at qxcbeventdispatcher.cpp:60 #18 0x00007f4658cb524b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffe3d30fd00, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:136 #19 0x00007f4658cbd296 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:118 #20 0x000000000040997f in main(int, char**) (argc=2, argv=0x7ffe3d3100c8) at ../main_x11.cpp:484