Version: 1.8.92 (using KDE 3.4.92 (beta2, >= 20051010) Level "a" , SUSE 9.3 UNSUPPORTED) Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) OS: Linux (i686) release 2.6.10 Although kmail doesn't crash on its own when such dialog boxes pop up, I still rated this as crash. Indeed, recently I got into a situation where xkilling kmail was the only way to get out of an infinite loop of modal dialog boxes. The troubles began when, we changed the SSL certificate on our mail server, and profitted from the occasion to normalize our host names. This change had an "interesting" side effect on kmail: it appears that all dialog boxes vaguely related to SSL are modal (login/password, SSL certificate hostname mismatch, TLS failure). Clicking cancel on each brings up the next dialog box in the series, which is also modal! Eventually you get back to the first one, for another loop. You don't get the opportunity to go into the configuration menu to fix the now bad hostname (remember: all 3 dialog boxes are modal!). While writing this bug report, I even managed to get kmail's UI completely frozen (IP address mismatch did no longer react to cancel at all...). But unfortunately the annoying "pop-to-the-foreground-on-mouseover-when-modal-dialog-open" misfeature still worked! Workaround: xkill kmail, and use a text editor to edit the config...
This is definitely a show stopper for me. And the "dialog loop" is extremely annoying. Fixing this ought to receive a very high priority...
can you still reproduce this problem with a current KDE version (e.g. 4.3) ?
While much progress is made (login boxes are no longer modal), there are still some left elsewhere in the code. One easy-to-find example: try composing a mail, and send it while "forgetting" to add a recipient. The error box that then pops up is modal, and prevents to open the addressbook via the composer window's Tools menu (...and all other items from the Composer's menu as well, but the addressbook is relevant because it helps getting the information that is being asked for).
I think your example is a bad one. If you have read the "you have to specify a recipient", you can already close the window. There is no need to keep that open, as you don't need to do anything further with the error dialog as to read and accept it. As a side note: you can use the tool menu from kmails main window during that dialog, as it's only modal to the composer window. The question here is not: are there _any_ modal dialogs in kmail (as this is nothing bad per se - just in certain situations), the question is: Can you reproduce the originally reported scenario?
You are right that this example is less bad than the initial one, as it doesn't contain ask for any input, and thus can be dismissed right away without the user needing to look information elsewhere in the application in order to fill it in. However, a similar modal box pops up when connection to the server fails for whatever reason (network disconnected, firewall rules, ...). In that case too, the box takes no input. But the user might want to keep it around in order to have the error message under his eyes when reviewing the config of the connection. Which he can't do, because the box is modal. And in the connection case, there is no second main window which he can use to access the config! Yes, the user could copy-paste the error text elsewhere, but why impose such hassle? And yes, in the case I tested (firewall rule), the error message was meaningless anyways ("Unknown error", instead of "Connection timed out" or somesuch), but that makes it 1+1=2 bugs, not 1-1=0 bugs that cancel out :-). Btw, the system error is accessible to the application even if non-blocking connect() system call is used, via the getsockopt(Sockfd, SOL_SOCKET, SO_ERROR, &error, &len) call. No, I can't reproduce the initial bug _exactly_ as reported, as the relevant certificates have expired since then, and I would get different errors. But the same _category_ of issue still exists, and that is what I was trying to point out.
In KDE 4.4 I don't see modal boxes anymore - everything is directed to the plasma notification system. So I consider this fixed until you state the opposite :)