Version: (using KDE KDE 3.3.1) Installed from: SuSE RPMs I use Kontact to access email on two imap servers. One of them went offline today during an upgrade and stopped authenticating users properly as a result, later. Why is this a problem with Kontact/KMail ? Whenever Kontact tries to access the server, authentication does not work - an error msg window "Authentication method Digest/MD5 probably not supported" pops up. This window blocks access to the remaining interface. (Error window "1") Immediately after acknowledging that error message, another dialogue pops up, prompting me to re-enter my password for the server. This window also blocks access to the remaining interface. (Error window "2") Whether I "OK" or "Cancel" the second window does not matter - my authentication method has not changed, and the server still does not let me log in. Kontact gets the same rejection as before, and dutifully pops up error window "1". Immediately afterwards, Number "2" opens, and we are in a loop. Unfortunately, both windows steal the focus - i.e., neither can I access the Kontact/KMail preferences to stop this behavior, nor can I exit the application. I am now trapped in an infinite loop and will click "OK" until the end of my days. My suspicion is that error window "2" (new password dialogue) should not open up at all when the athentication method is unsupported, since it will not fix the problem. That as an aside. What I really think is more general: It should not be possible to have a continuous series of windows popping up which steal the focus forever. Adding extra delay times would be one solution; reducing the number of windows which block the entire interface to a bare minimum would be another solution. Cheers!
Here are two more specific: 1) The server's actual error message is "user not found" [not KMails problem, but this is why reentering the password will abrolutely not help] 2) The loop becomes infinite after clicking on a folder of the defunct IMAP account once. After that, KMail/Kontact will never stop trying to access the server, no matter what (even if you click onto another folder in a working IMAP account later) 3) If you never check the IMAP server in question (i.e. do not check on startup, nor have interval checking enabled, but have the server's folders displayed because the server was used duringa previous session), Kontact still tries to access the IMAP server once (and only once). This should not happen.
definitely true and very annoying. It happened to me while adding a "connected" IMAP account and choosing the wrong password exchange method. The silly window would popup continuously and I couldn't return to the settings dialogue to perform the change; I had to exit the application several times in order to change the setting to the correct form. This bug is a real showstopper and extremely annoying. I heartly suggest to either: a) set a retry count (and show how many retries are left) b) Better still: change the buttons to "Retry", "Remain disconnected" and actually _stop_ the imap thread until the user decides to retry again (say like in Apple Mail.app)
this problem is still present in KDE 3.5.1, I just run to it with kmail because my Exchange (imap) account got blocked ... the workaround was to kill the imap process and somehow disable the account (changing the server name is sufficient, although some special function to disable unused accounts without the need to actually delete them would be nice ...) I tried at the first to use kwin advanced properties to stop the error message from stealing focus, but this did not help, it has just led to a battle between kwin and the error dialogue, I could have the kmail settings window on top but I was unable to change anything
*** Bug 81269 has been marked as a duplicate of this bug. ***
Still a problem in 3.5.5.
*** Bug 94565 has been marked as a duplicate of this bug. ***
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kontact (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Thank you for following up on this. This was a long time ago. Unfortunately I no longer have a current version to be able to test this. Good luck! & Best wishes, Volker On Sep 24, 2016, at 3:30 PM, Denis Kurz via KDE Bugzilla <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=94168 > > Denis Kurz <kdenis@posteo.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|CONFIRMED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #7 from Denis Kurz <kdenis@posteo.de> --- > This bug has only been reported for versions before 4.14, which have been > unsupported for at least two years now. Can anyone tell if this bug still > present? > > If noone confirms this bug for a Framework-based version of kontact (version > 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in > about three months. > > -- > You are receiving this mail because: > You reported the bug.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.
Thanks again! On Jan 7, 2017, at 6:44 PM, Denis Kurz <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=94168 > > Denis Kurz <kdenis@posteo.de> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |kdenis@posteo.de > Status|NEEDSINFO |RESOLVED > Resolution|WAITINGFORINFO |UNMAINTAINED > > --- Comment #9 from Denis Kurz <kdenis@posteo.de> --- > Just as announced in my last comment, I close this bug. If you encounter it > again in a recent version (at least 5.0 aka 15.08), please open a new one > unless it already exists. Thank you for all your input. > > -- > You are receiving this mail because: > You reported the bug.