Bug 279118

Summary: When filtering on unread, messages disappear as soon as you read them
Product: [Applications] kmail2 Reporter: Jonathan M Davis <bugs.kde.org>
Component: message listAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jonathan M Davis 2011-08-02 02:15:33 UTC
Version:           unspecified (using KDE 4.7.0) 
OS:                Linux

Kmail lists itself as 4.7.0 just like KDE, so I don't know what application
version number (2.x) it is, hence why I left it as unspecified.

In kmail 1, if you filtered on message status, selecting "unread", and then selected a message, it was changed to read without changing the list of messages in the window. So, after selecting the unread message, you could click on its parent. Once you messed with the filter again, then they disappeared because they weren't unread anymore, but until you messed with the filter, they stayed.

In kmail 2, as soon as you click on an unread message when filtering on "unread," that message and all of its ancestors disappear. The message is still in the box fortunately, so you can at least read it, but you've completely lost where it is. It's understandable that it no longer be listed, since it's no longer unread, but it makes it _much_ harder to look at the message in context. I'd _very_ much like kmail 2 to act like kmail 1 in this respect and not make the message disappear from the list as soon as you click on it. It should stick around until you mess with the filters again.

Reproducible: Always

Steps to Reproduce:
Filter your message list on the "unread" status.
Select a message which is unread.

Actual Results:  
The message and its ancestor messages in its thread all disappear.

Expected Results:  
The message and its ancestor messages remain listed until you mess with the filters again.
Comment 1 Jonathan M Davis 2011-08-03 02:33:19 UTC

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