using trunk (r1085248) Reproduced in my inbox folder. what works: - select message #1 - wait until the message is displayed - click on message #2 The 2nd message is displayed what doesn't work: - select message #1 - click on message #2 before the first mail content is displayed -> The message #1 is displayed but clicking on any message won't have any effect. kmail is not frozen: Changing folder or selecting another message in the list is possible (kmail(6571) MessageList::Core::View::mousePressEvent: Left hit with selectedIndexes().count() == 2), but the content isn't displayed (deleting messages is also impossible)
Sorry, I can't reproduce this. I even tried to introduce artifical delays using usleep() to the following pieces: - to QGpgMEVerifyDetachedJob for delaying signature verifying - to Search::parseStream() in the Akonadi server to delay Contact searching - to ViewerPrivate::parseMsg() to delay showing a message With neither of these methods, I could reproduce your bug. Sometimes message switching takes some time with those delays, but the second message is always correctly activated.
I can see the same problem now as well, without deleting messages even.
For me, that only seems to happen after a failed ItemModifyJob ("17 NO Item was modified elsewhere, aborting STORE"). That ItemModifyJob is from KMSetStatusCommand, trying to mark a message as read. Not all failed ItemModifyJobs seem to trigger this, though. I added debug output to Akonadi::SessionPrivate::writeData() and to AkonadiConnection::slotNewData(). It seems that the ItemFetchJob which is started to get the message is written out to the socket, but never arrives on the server, I see the debug output from writeData(), but not from slotNewData(). Both KMail and the Akonadi server sit in the event loop and are not blocked. Very strange.
The Akonadi server still accepts commands for other connections, so it is either a problem with that specific connection or a problem on the sending side.
Fixed according to Volker.