334517 - mailnews.mark_message_read.delay.interval sporadically ignored

Status: RESOLVED DUPLICATE of bug 316933

(Thunderbird :: Mail Window Front End, defect)

Description

[Adam Roach [:abr]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: version 1.5 (20051201)

With the 1.5 build, Thunderbird occasionally ignores the value of the mailnews.mark_message_read.delay.interval configuration variable. This was not a problem in the 1.0.x versions of Thunderbird.

There appears to still be a slight difference between having the mailnews.mark_message_read.delay flag set -- when the flag is "true," there's a brief (about 3 second) delay before a message is marked as read, whereas when the flag is "false," the message is marked as read instantly.

By changing the values of these variables at random, I can get the problem to go away -- but it does come back occasionally.

Reproducible: Sometimes

Steps to Reproduce:
1. In the options window, under Advanced, on the "General" tab, select
   the checkbox for "Wait [___] seconds before marking a message as read."
2. Enter a relatively large value (e.g. 60).
3. Hit "OK"
4. Go to the 3-pane mail window, and click on various messages.
5. If the problem does not exhibit the first time, revise the timeout
   value and try again.

Actual Results:  
Messages are marked as read after about 3 seconds, instead of the 60 seconds requested.

Expected Results:  
The messages should not have been marked as read until after the amount of time indicated.

This appears to be a problem under OS X as well. There are a couple of threads on the topic over at mozillazine:

http://forums.mozillazine.org/viewtopic.php?t=367866
http://forums.mozillazine.org/viewtopic.php?t=367900

The bug *can* be worked around for short lengths of time by randomly changing the delay value, but this is very annoying and tends to stop working without provocation.

Since the mozillazine discussions note issues with timers on the Intel Duo systems, it might be relevant to note that this is happening on a Pentium 4 HT; if the timers have concurrency issues in the new codebase, the hyperthreading (which effectively acts as two cores) might be triggering the bug.

Comment 1

[Mike Cowperthwaite]

This appears to be the same as bug 316933, which is duped (via another bug) to 
bug 318419 -- the fix will be in TB 1.5.0.2, which should be released shortly.

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