Closed Bug 232967 Opened 21 years ago Closed 4 years ago

unread message marked read when changing/switching folders

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla.mozilla.org-3, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: testcase, Whiteboard: [datalossy]) 

Steps to reproduce:
1. Select a message in a folder
2. Mark the message unread
3. Change to another folder
4. Change back to the original folder

Actual results:
The message that was marked unread is marked read.

Expected results:
The message should retain its unread status, unless I explicitly select the
particular mail (not the folder) or mark it read.

This happens in both IMAP and local folders. I am using Thunderbird 0.4 on WinXP.

This issue was raised in bug 186504, but as far as I can see it was never
adressed. In bug 186504 comment 16 it was mentioned that some issues in that bug
should be spun off to other bugs, but I don't think that ever happened.
Just tested and it seems to be fixed. Closing as WFM
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
I still experience this error using Thunderbird 1.1 alpha 1. The problem is the
same for IMAP folders, local folders and RSS feeds. Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
so, opening the folder selects the message using the same mechanism as clicking
on the message?
Keywords: testcase
This bug has just surfaced on the Mac version of TB 1.5.
(In reply to comment #4)
> This bug has just surfaced on the Mac version of TB 1.5.

Actually, it occurs in TB 1.5 only if the AutoMsgSelect extension is also installed. I don't know if the extension has a bug that became activated with TB 1.5, or if the extension activates a bug in TB 1.5.
(In reply to comment #5)
> (In reply to comment #4)
> > This bug has just surfaced on the Mac version of TB 1.5.
> 
> Actually, it occurs in TB 1.5 only if the AutoMsgSelect extension is also
> installed. I don't know if the extension has a bug that became activated with
> TB 1.5, or if the extension activates a bug in TB 1.5.

So you do all the steps in comment 4, especially step 2, then it doesn't happen on the mac unless you have AutoMsgSelect installed?

(Christian Schmidt in comment #2)
> I still experience this error using Thunderbird 1.1 alpha 1. The problem is the
> same for IMAP folders, local folders and RSS feeds. Reopening.


Christian,   are you still able to create this problem?



> Christian,   are you still able to create this problem?
Yes, it is still there in 1.5 and version 3 alpha 1 (20060711).

A workaround is to go to Tools > Options > Advanced > General and uncheck "Remember the last selected message". I still think that there is a problem when this option is checked, though. Thunderbird should not only remember which message was selected but also its read/unread state.
QA Contact: front-end
Blocks: 438257
I belive there are "automatically mark message as read" involved in this, if you choice mark as read immediately or after few seconds. You see described behavior.
I do not use auto marking as read therefore not experience problems but can reproduce as descibed
Assignee: mscott → nobody
Severity: normal → minor
Status: REOPENED → NEW
Version: unspecified → Trunk
> A workaround is to go to Tools > Options > Advanced > General and uncheck
> "Remember the last selected message".
This checkbox was removed in bug 448694.
There are conditions, where this bug is easily reproducible in TB3.

1. Set folder retention policy to 'Delete all but the most recent XXX messages' and the total message count of the messages in this folder esceeds the XXX value.
2. Make sure there are new (unread) messages in this folder and the total count of the messages exceeds the XXX value.
3. Select the folder name in the folder pane and notice, that the current unread message in this folder changes it's status to read.

This happens when old messages are deleted from the folder. I'm sure it is important to fix this bug, just because one can easily lost important mail just by accidentaly mark it as read (especially when using 'Threads with unread' view).

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.1pre) Gecko/20090706 Shredder/3.0b3pre
bug 284030 and bug 289375 might not be the same issue, but seem like they should be related.
Blocks: 284030, 289375
Component: Mail Window Front End → Folder and Message Lists
QA Contact: front-end → folders-message-lists
it might be somehow related to my bug 511105
bienvenu, nikolay, I can reproduce using comment 0 steps, only if mark messages unread after N seconds enabled - which is a TB default.  Does not happen if Automatic mark unread is unchecked (which is what I normally use). imap. 

Seems like this would be a good bug to tackle (or bug 199433), before attempting to address  other bug reports about messages changing their read/unread state.  Or do you think bug 199433 comment 3 must be addressed first?
Severity: minor → normal
Depends on: 199433
Summary: unread message marked read when changing to folder → unread message marked read when changing/switching folders
Whiteboard: [datalossy]
Wayne, are you saying that the mark read after selection doesn't respect the mark read interval (e.g. 10 seconds), or that we mark the message read at all after automatically selecting the remembered message?
correct, doesn't respect the mark read interval - the _user_ hasn't reselected the message.
er, are you saying we mark the message read immediately, *or* we shouldn't mark the message read at all because the user hasn't reselected the message. Those are two different things.
it should never change the message if the user hasn't clicked on it. so i think the answer to both questions is yes. it should remember that the message was previously selected, and not alter the message. ditto for the other bugs, which have different steps.
(In reply to comment #19)
> it should never change the message if the user hasn't clicked on it. so i think
> the answer to both questions is yes. it should remember that the message was
> previously selected, and not alter the message. ditto for the other bugs, which
> have different steps.

better stated ... it should remember that the message was previously selected, previously altered to the current state(unread), and not alter the message back to read.
I think anyone who doesn't want auto-mark as read would also not want "remember last selected" message. If you look at the options UI for the delay on marking read, it says that the message will be marked read "on display", not "on select", and the message is getting displayed in this case, right? I.e., the message pane is not hidden. Cc'ing Bryan for his input. I certainly understand the argument that the user didn't explicitly select the message, but there's all sorts of ways to cause a message to get displayed that don't involve clicking on the message.
good point about the pref wording - but I wonder if wording was intentional *and* deemed to be highly desired workflow, or a weasel way of dealing with the current behavior. Or perhaps purely accidental/coincidence :)

And yes there's all sorts of ways to cause a message to get displayed that don't involve clicking on the message.  But I'm thinking that clicking (or selecting) isn't precisely the point for the users that are affected.  Having intentionally marked a message unread as their last action on the message is I think the main point.

Other points:
- now that we have tabs as a primary UI feature AND we encourage it's usage, there is additional and perhaps more chance for the behavior in Bug 534597 - Messages gets marked unread when changing back from another tab
- is not "remember last selected" a hidden pref? 
- can we really say that (on average) anyone who doesn't want auto-mark as read would also not want "remember last selected" message _except_ as a workaround - I have the former, but not the later and indeed highly desire "remember last selected" message
- if someone's preferred workflow is consistent with Automatic mark enabled (which is the default and presumably this is the majority of users) and they have no other problems with it, then many face this bug and I think they would, as I did, find it quite irritating, bordering on stupid (to quote someone else, no offense intended to anyone) because the user just marked the message as unread 


personal data point - A few years ago this bug is one reason I changed to disable Automatically mark (I had been using ~10 sec) on all my systems.  In some accounts I do frequent searches. Frequent quick searches + unwanted automatic unread make for not nice workflow. Which is not to say I would ever go back to automatic mark unread under any circumstances ... I still think this should this bug be fixed.
Blocks: 534597
I have this problem starting with Thunderbird 14 running under linux.
(In reply to David :Bienvenu from comment #21)
> I think anyone who doesn't want auto-mark as read would also not want
> "remember last selected" message. If you look at the options UI for the
> delay on marking read, it says that the message will be marked read "on
> display", not "on select", and the message is getting displayed in this
> case, right? I.e., the message pane is not hidden. Cc'ing Bryan for his
> input. I certainly understand the argument that the user didn't explicitly
> select the message, but there's all sorts of ways to cause a message to get
> displayed that don't involve clicking on the message.

Blake, this behavior has happened so long that it may no longer matter. But I would like to dispose of this bug such that we either close it wontfix, or have a path forward. 

So with your magical ball skills, what are your thoughts on this and comment 22?
Flags: needinfo?(bwinton)
p.s. note the blocked bugs: bug 284030, bug 438257, bug 534597
Yeah, I can see both points of view here, and I think I would be happy with either changing the code to only mark when the user selects a message (and changing the option text to indicate such), or leaving it as it is, because that's been the behaviour for so long.  I mean, we don't really know when a user has read a message, only when we've displayed it, which is part of the reason for the timer, right?  I think people will probably be confused either way, but leaving a message unread seems like the less destructive confusion.  (Having said that, I just tested it in Apple's Mail.app, and it clears the unread state when switching back, so leaving it as is will match at least one other mail client.)

So it comes down to minor differences, and in the interest of getting people to work on more important things, I'ld say close it wontfix.
Flags: needinfo?(bwinton)

Per comment 26

Status: NEW → RESOLVED
Closed: 19 years ago → 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.