Bug 281085 - conflict resolution dialogue sometimes locks up the GUI
Summary: conflict resolution dialogue sometimes locks up the GUI
Status: RESOLVED DUPLICATE of bug 275789
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: Git (master)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-31 06:57 UTC by Jonathan Marten
Modified: 2011-09-18 06:51 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***