Bug 225576

Summary:	KMail becomes unresponsive when selecting messages too quickly
Product:	[Applications] kdepim	Reporter:	Christophe Marin <christophe>
Component:	messagelist	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	Keywords:	akonadi-ports-regression
Priority:	VHI
Version:	4.5
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Bug Depends on:
Bug Blocks:	223438

Description Christophe Marin 2010-02-05 02:40:45 UTC

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)

Comment 1 Thomas McGuire 2010-02-05 11:57:50 UTC

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.

Comment 2 Thomas McGuire 2010-02-10 17:18:00 UTC

I can see the same problem now as well, without deleting messages even.

Comment 3 Thomas McGuire 2010-02-12 10:40:42 UTC

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.

Comment 4 Thomas McGuire 2010-02-12 10:49:29 UTC

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.

Comment 5 Thomas McGuire 2010-04-12 17:05:32 UTC

Fixed according to Volker.