Bug 3951 - First unread message selected surprisingly in some scenarios
Summary: First unread message selected surprisingly in some scenarios
Status: NEW
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Message List (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 enhancement
Assignee: users
Depends on:
Reported: 2018-01-18 07:46 CET by Shai Berger
Modified: 2018-04-30 22:58 CEST (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Shai Berger 2018-01-18 07:46:02 CET
I've seen three scenarios, which are really two, where the first unread message in the folder is selected. In some of these scenarios it is annoying because it moves the selection far from where it was (and where it was expected to be). In all of them it is also annoying in combination with the "mark message as read: when selected" setting, because if one is not careful, messages get marked as read when the user wanted to keep them unread.

The first scenario is when the selected message becomes unavailable to display, and not through an explicit delete or move operation. I've seen two cases of this:

(1) When the selected message is moved by an action (e.g. marking as spam)

(2) When searching the folder, and the selected message does not match the search criteria, but some other unread message does

The second scenario is the converse -- when you're in a folder, no message is selected, but unread messages suddenly become available to display

(3) After searching a folder using criteria which match nothing, no message is selected. Clearing the search criteria then selects the first unread message

Ideally, in case (1) above the behavior should be ruled by the next_on_delete setting, and in cases (2) and (3) by the default-selection-when-entering-a-folder setting. I'd also consider "no selection" as reasonable behavior in all three cases, but this may just be my bias (my default-selection-when-entering is set to "previously selected; none").
Comment 1 Tristan Miller 2018-04-05 16:09:48 CEST
Scenario #1 is a duplicate of Bug 3840.
Comment 2 Shai Berger 2018-04-30 22:58:53 CEST
As noted in Bug 3840#c3, Bug 1857 is also related.