Email messages are marked as read even if "Mark message read after displaying for x second(s)" is unchecked

VERIFIED DUPLICATE of bug 234121

Status

VERIFIED DUPLICATE of bug 234121
14 years ago
13 years ago

People

(Reporter: keiron, Assigned: mscott)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

When I click on a newly received email, it is marked as read immediately, even
though I have unchecked the Tools > Options > Advanced > General Settings >
"Mark message read after displaying for x second(s)".

Reproducible: Always
Steps to Reproduce:
1. Uncheck Tools > Options > Advanced > General Settings > "Mark message read
after displaying for x second(s)"
2. Click on an unread email

Actual Results:  
The email is immediately marked as read.

Expected Results:  
It should not have marked the email as read :).

Comment 1

14 years ago
that's not a bug - if you read a message, we mark it read. That setting is just
about delaying the marking read, not skipping it entirely.
(Reporter)

Comment 2

14 years ago
Ok then, but I don't want my message to be marked as read as soon as I have
clicked on it. Just because I have clicked on an email, it doesn't mean I have
read it.

It makes sense to disable the automatic marking as read completely when the
checkbox is question is unchecked.

Comment 3

14 years ago
you could set the delay to a very large value.
(Reporter)

Comment 4

14 years ago
Yes, that is what I do do. However, I still believe it makes sense for the mark
as read to be disabled when this option is unchecked :).

Comment 5

14 years ago
that's the way you'd want it to work; I understand. But that could mean that
everyone who wants the current behaviour would have to check that box and set
the value to 0.  I think you might be in the extreme minority, which means you
probably have to put up with a little inconvenience :-)
(Reporter)

Comment 6

14 years ago
No, this can be resolved by having the default setting for this option as
checked, with the default value as 0 (or more to my liking, 2-3). :).

Comment 7

14 years ago
Duplicate of bug #234121

I agree with the Reporter. There are two settings (1:box unchecked, 2:box
checked, zero timeout) which lead to the same behavior - mark message read
immediately. There is no setting which leaves message unread undefinitely (until
double-click or being marked read explicitly). This does not make sense,
especially that a *a lot* of people prefer the latter behavior. 
 
Setting the timeout to a large value is just a workaround with its own problems,
see bug #226551.

> I think you might be in the extreme minority, which means you
> probably have to put up with a little inconvenience :-)

You might get a job at MS public relations with this attitude :(

Comment 8

14 years ago
In reply to this bug--I'm using Mac OSX and I'd like to confirm it there.

I have the message display window pulled all the way down in TB--that is, when I
select a message there is no way for it to display. I must double-click on a
message to read it.

For old messages that I have marked as unread they stay unread until I
double-click on them.

New messages however continue to read themselves--without ever displaying. This
is a bug. It continues through build 20041017.

I understand that if the message is displayed in a display pane then it would
technically be read, but if the display pane is disabled or doesn't display
messages (as I have done) new messages should remain unread until I manually
(double-click) open them. 

Perhaps there needs to be a way in the prefs to let TB know that the message
display pane has been disabled or dragged out of view so that the read selected
message functionality is disabled. If so, please add it, but right now, TB
marking new messages as read without them ever being shows in a display window
seems like a bug that needs a fix.

Comment 9

14 years ago
(In reply to comment #5)
> that's the way you'd want it to work; I understand. But that could mean that
> everyone who wants the current behaviour would have to check that box and set
> the value to 0.  I think you might be in the extreme minority, which means you
> probably have to put up with a little inconvenience :-)

NO !

That is a very useful behavior when using shared imap folders. if there are 10
peaple on a team using the same folder i can just mark as read every message i
watch, and if i set the time to a number like 999999 and leave the thunderbird
open and it time reaches even so the message will be marked read

i think and i insist there has to be a way to disable it ...

sorry by my english

Paulo Cunha

Comment 10

14 years ago
I have also encounered this problem using Thunderbird version 0.9 (20041103) 
under Windows 2000. Please could we have some combination of options which 
allows messages to be left unread until a keypress is used to mark them as read.

I, and many others out there, use this scheme. For example, I mark messages as 
read when I have dealt with them. This means that the main tree view 
showing "unread" messages which have been filtered into loads of subfolders 
actually amounts to a sort of TO DO list... This really would be useful!

Finally, bug #226551 prevents one possible workaround. I tried setting the mark 
as read delay to a large number, but mozilla turns this into a negative number 
and therefore still marks the messages as read immediately! :-(

Comment 11

14 years ago
I have to speak up for what appears to be the majority (Keiron, Sandor, Nathan,
Paulo, Chris) on this one: I need to have the option not to mark a message as
read when it has only been read in the preview pane.  That is logically what
that option should mean:  It says "Mark message read after displaying for __
second(s)."  If that box is unchecked, the logical expectation would be that a
message is not marked read after simply being displayed in the preview pane --
the user has to open the message in its own window to mark it as read.  This is
an option in Outlook, and while of course the point isn't to make an Outlook
emulator, it is a reasonable user expectation.  And that's especially so because
the current behavior could be available by checking the box and setting the
value to 0.  This is the biggest UI fault I've found yet in my few days of
testing Thunderbird.

Comment 12

14 years ago
Judging by the comments here, andthe fact that this same bug keeps getting
re-reported, this obviously is bugging a lot of people. Sure wish it could be
fixed soon.

Comment 13

14 years ago

*** This bug has been marked as a duplicate of 234121 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE

Updated

14 years ago
Status: RESOLVED → VERIFIED

Comment 14

13 years ago
when i reply to a message by selecting an unread one, i'd excpect it to be marked as read; this doesn't happen. if not by default behavior, then an option to do this.  

i've tried: 
options: mark message as read when viewing for 0/1 seconds (checked and unchecked)

w xp sp1; t/b rc1

Comment 15

13 years ago
Still a problem in 1.5, and maybe even worse since any large value set in the renamed "Wait x seconds before..." field seems to result in the message getting marked read immediately as does unchecking the box.
(Todd in comment #14)
> when i reply to a message by selecting an unread one, i'd excpect it to be
> marked as read; this doesn't happen. if not by default behavior, then an option
> to do this.  
> 
> i've tried: 
> options: mark message as read when viewing for 0/1 seconds (checked and
> unchecked)
> 
> w xp sp1; t/b rc1 

(James in comment #15)
> Still a problem in 1.5, and maybe even worse since any large value set in the
> renamed "Wait x seconds before..." field seems to result in the message getting
> marked read immediately as does unchecking the box.

James' problem (not sure about Todd's) are Bug 316933 which ultimately resolves to Bug 318419.  Bug 318419 has been picked up on branch 1.8.0.2 so I think it's fixed in Thunderbird 1.5.0.2, even though it's not in the release notes.
You need to log in before you can comment on or make changes to this bug.