Created attachment 106201 [details] screenshot of error message After restoring a message from backup in the web interface of my mail provider, FastMail, Trojita chokes on (I strongly suspect) that message. To wit, I get a ParseError: getPossiblyBackslashedAtom: did not read anything with clarification: * 22 FETCH (FLAGS (\Seen $X-ME-Annot-2 werk [EXPUNGED]) UID 2006 MODSEQ (673451)) ^ here Somebody else already established from the RFC that ] is not allowed there <http://www.lumisoft.ee/Forum/yaf_postsm24658_Invalid-IMAP-flags.aspx#post24658> and I guess this is baked into Trojita: flag-keyword = atom ATOM-CHAR = <any CHAR except atom-specials> atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards / quoted-specials / resp-specials resp-specials = "]" So this seems to be a clear server-side issue. I will contact my mail provider. I'll see if I can find a more lenient client that will allow me to clear the offending keyword. I don't know whether Trojita is supposed to be able to deal with this, but after retriggering the issue by re-opening the mailbox with the offending message a couple of times, Trojita locks up the window manager hard. Namely, I need to go to a console (Ctrl-Alt-F2) and sigterm Trojita from there to get the window manager back responding. I do think that is not supposed to happen.
The FastMail team have confirmed the server-side bug, so what remains is the hard lock-up.
(In reply to Erik Quaeghebeur from comment #0) > * 22 FETCH (FLAGS (\Seen $X-ME-Annot-2 werk [EXPUNGED]) UID 2006 MODSEQ > (673451)) > > ^ here Yes, this was a server-side bug. I don't think that making our parser more relaxed in this context would be reasonable. > I don't know whether Trojita is supposed to be able to deal with this, but > after retriggering the issue by re-opening the mailbox with the offending > message a couple of times, Trojita locks up the window manager hard. If a window manager locks up, it's a bug in the window manager, not in Trojita. I would love to improve Trojita in order to ensure that it doesn't do crazy things that might crash some WMs, but I don't know what crazy thing it was doing. Maybe you ended up with an endless reconnect loop with plenty of dialog windows on top of each other? That should not happen, and as far as I can tell, it doesn't happen for me. Reporting IMAP errors is just a simple QMessageBox. I get an error (from e.g. reconnects or network errors) every now and then, and my WM survives just fine. Either way, without knowing what your WM dislikes and how to reproduce this, I cannot fix it, sorry.
"locks up the window manager hard" This needs a better explanation on what actually happened. It *might* be a stale mouse grab, caused by some accidental click-drag, unreleased because trojita went unresponsive for the bad mailbox? Can you cause this at will?
Created attachment 106208 [details] screenshot of two dialogs spawned by Trojita
(In reply to Jan Kundrát from comment #2) > If a window manager locks up, it's a bug in the window manager, not in > Trojita. I would love to improve Trojita in order to ensure that it doesn't > do crazy things that might crash some WMs, but I don't know what crazy thing > it was doing. To be clear, this is KWin 5.8.6 in combination with Frameworks 5.34.0. > Maybe you ended up with an endless reconnect loop with plenty of dialog > windows on top of each other? No, before the WM becomes totally unresponsive, I get a little time to do stuff, and I can verify that it's not multiple dialogs on top of each other. I can add something, however (see below). (In reply to Thomas Lübking from comment #3) > "locks up the window manager hard" > This needs a better explanation on what actually happened. > It *might* be a stale mouse grab, caused by some accidental click-drag, > unreleased because trojita went unresponsive for the bad mailbox? It is not something like that, I think. > Can you cause this at will? Yes. Every time I open the mailbox with the offending message, it happens. However, what I missed was the fact that Trojita spawns to dialogs and neither can be OK'd away. I managed to make a screenshot of the second one over the one I already gave a screenshot for. I've attached it.
Further testing results, this time doing things with an open process monitor: * kwin and X jump up in CPU usage (to about 4% and 14% respectively) * when I switch to a console (Ctrl-Alt-F2), their CPU usage goes down I do not know whether we know enough to reassign this to kwin.
This is interesting :). I looked at the code that opens these dialog boxes. Both of them in the end call a helper like this: auto box = new QMessageBox(icon, title, message, QMessageBox::Ok, <main app window>); box->open(); And I'm able to reproduce this :(.
Created attachment 106211 [details] testcase-twodialogs.cpp Erik, running this locks up kwin for me as well. I'm on the git master of all of KF5 and all of plasma as of last week or two, with Qt from 5.9 git. Does it cause the same lockup for you as well?
(In reply to Jan Kundrát from comment #8) > Created attachment 106211 [details] > testcase-twodialogs.cpp > > Erik, running this locks up kwin for me as well. I'm on the git master of > all of KF5 and all of plasma as of last week or two, with Qt from 5.9 git. > Does it cause the same lockup for you as well? Yes. (I needed to add -fPIC, but that isn't relevant probably.) I'm using Qt 5.6.2. Does someone have another WM installed to test it there?
Created attachment 106212 [details] kwin supportinfo for jkt
Run the attached test case, observe that KWin stops being responsive.
Doesn't really knock out fluxbox, but once you pass focus to the "wrong" dialog, they apparently start a race on the window focus and you cannot pass it at will. The reason seems to be client side modality implementation. Once the focus is attempted on the leader, it's effectively passed to the warn dialog and further focus distribution via the WM fails. I need to click (in contrast to a FFM policy) one of the modal dialogs stop this. I'll add that I at some point added some code to fluxbox (it's in git master) to deal with "stupid clients that are top stupid to play WM modality" I guess I don't have to point out that there is no problem when you compile the demo against Qt4 ... (yes, tried)
Running the attached testcase, I also observed the weird behavior. Depending on the order I try to close the windows, I got 100% CPU usage (distributed between all processes), not being able to click into other windows, but still move them, etc. Really odd.
With if (ac && ac->isModal()) { if (hasTransient(ac, true)) { return false; } } in allowWindowActivation(), kwin is no longer knocked out by the demo application, but I'm not sure that this is the approach we want to take. If the parent window is activated, it makes sense to activate its modal instead. I think that Qt should be more careful when playing input focus tossing games with the window manager.