Bug 281085

Summary:	conflict resolution dialogue sometimes locks up the GUI
Product:	[Applications] kmail2	Reporter:	Jonathan Marten <jjm>
Component:	general	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	2Kmm, a, hans.maulwurf, ht990332, kbug, montel, woebbeking
Priority:	NOR
Version:	Git (master)
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Jonathan Marten 2011-08-31 06:57:20 UTC

Version:           Git (master) (using Devel) 
OS:                Linux

My current KMail2 setup includes a filter which appears to trigger the conflict resolution dialogue frequently.  That appearing is bug 259574;  however, a secondary problem is that sometimes when this box appears neither it nor the main KMail window will respond to anything - mouse clicks, menus or keys.  There is no high CPU usage and no Akonadi activity, and the windows are drawn correctly, but the only way out is to kill the KMail process.

Restarting KMail resolves the conflicts and from then on everything appears to be normal (until the next time).


Reproducible: Sometimes

Steps to Reproduce:
Wait for the conflict resolution dialogue to appear.


Actual Results:  
GUI sometimes locks up, need to kill the Kmail process.


Expected Results:  
GUI should continue working.

Comment 1 Laurent Montel 2011-08-31 07:03:41 UTC

How do you get this dialog ?
(more easy to reproduce this bug :) )

Comment 2 Jonathan Marten 2011-08-31 09:43:29 UTC

The filter that seems to trigger the CR box is a mailing list that has an annoying "[List name]" prefix added to the subject line of every email.  So I'm trying to remove that and filter the mail into a specific folder, with a filter set up as:

Match any of the following
List-Id contains address1.yahoogroups.com
List-Id contains address2.yahoogroups.com

Rewrite Header - Subject replace "\[.*\] *" with (null string)

Move into Folder - Local Folders/destination

Apply to incoming messages - all but online IMAP accounts
Apply on manual filtering
If filter matches, stop processing here

Many, but not all, incoming messages to this list trigger the CR box.  Will add more detail when it happens next.

Comment 3 Jonathan Marten 2011-08-31 17:39:00 UTC

The CR dialogue shows:

Modification times - shown in conflict (red) colour
Left: just before now
Right: exactly 1 hour before left
(current system time zone = BST)

Data - shown in normal colour:
Left: "Subject" is the desired result after replacing with the regexp as above.
Right: "Subject" is the original as received from mailing list.

Comment 4 Andrew Gaydenko 2011-09-04 06:57:42 UTC

Please, confirm the issue as far as I'm next in the boat.

Comment 5 Andrew Gaydenko 2011-09-04 07:00:45 UTC

Just want to add, I use 4.7.0 (under Arch Linux) rather git version.

Comment 6 Jonathan Marten 2011-09-06 06:35:49 UTC

More information on what happens:

When the GUI locks up, the CR dialogue is in front of the KMail main window and cannot be moved behind.

System tray popup menu is still active.  "Quit" can be chosen and will quit KMail cleanly, "Cancel"ing the confirmation will not quit KMail but it will still be unresponsive.

"Configure Kmail" or "New Message" can be used to open a new config or composer window, but they are also unresponsive.

Comment 7 Hussam Al-Tayeb 2011-09-06 12:09:45 UTC

I can reproduce then when I'm getting an spam email that contains an attachment and this email is going to cause an conflict. Then while downloading the email, I click 'check email' again. this causes the gui lockup. regular conflicts don't cause a gui lockup.

Comment 8 Manuel Mommertz 2011-09-10 08:33:17 UTC

I can confirm this behavior with kmail from 4.7.1. I get this sometimes when bogofilter processes my mails.
Appearing of the conflict dialog happens severeal times a day but it freezes 'only' sometimes (still more then once a day).

A detail not mentioned yet:
The conflict dialog freezes in the moment a button is pressed. Until then mouseover effects are drawn. The 'button down'-state itself isn't rendered anymore.

Comment 9 Jonathan Marten 2011-09-18 06:51:46 UTC


*** This bug has been marked as a duplicate of bug 275789 ***