User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 With "Automatically mark messages as read" set to a delay, clicking on an unread message and then arrow-keying to or clicking on a read message doesn't appear to stop the mark-as-read timer, and the original message is marked as read when it triggers. Reproducible: Always Steps to Reproduce: 1. Set "Automatically mark messages as read" to 3 seconds 2. Click on an unread message. 3. Immediately move to a read message. Actual Results: The original message is marked as read after 3 seconds. Expected Results: The timer should be canceled after moving off the message. Reproduced on both IMAP and newsgroup accounts. As far as I can tell, the only way to prevent it is to explicitly mark the message as unread before moving off of it. This bug can be hard to notice, causing messages to be marked as read even after you've moved on to read other messages, which can have serious consequences if the original message was important.

Get IMAP log with timestamp, and check when "uid xxx store flag \Seen" is requested. > Getting log : https://wiki.mozilla.org/MailNews:Logging > Timestamp : Bug 402793 Comment #17 > IMAP command & response : http://tools.ietf.org/html/rfc3501

I can do that, but, as I noted, this isn't limited to IMAP. It happens for (offline) newsgroup accounts too. Would the IMAP log still be helpful?

(In reply to comment #2) > Would the IMAP log still be helpful? Yes, of course. If "store flag \Seen just after 3 second you move cursor" is seen in IMAP log(online) for any new message, it's an valuable evidence. To see timing of "new mail is clicked", get log with IMAP folder of offline-use=off (fetch body is requested when mail is clicked), please.

This is very likely a regression from bug 474701 (whose regressions we are tracking against but 497199). We have no unit tests covering the marking read logic and a lot of things related to message display have changed. I would not bother with the IMAP log.

For what it's worth, I've fixed this in my own installation by adding ClearPendingReadTimer() immediately below if (!this.active) return true; in MessageDisplayWidget_onSelectedMessagesChanged() in messageDisplay.js. No idea if that's the best place for the call, but it seems to do the trick.

(In reply to comment #5) > For what it's worth, I've fixed this in my own installation by adding > > ClearPendingReadTimer() > > immediately below > > if (!this.active) > return true; > > in MessageDisplayWidget_onSelectedMessagesChanged() in messageDisplay.js. > > No idea if that's the best place for the call, but it seems to do the trick. Can you create a patch and post it here ? (see https://developer.mozilla.org/En/Developer_Guide on how to achieve that)

Done.

Comment on attachment 390791 [details] [diff] [review] Clear pending read timer when switching messages Thank you for providing a patch! Any fix for this problem is going to need mozmill tests so that we can ensure that the fix works and that we don't regress this functionality in the future. Documentation on how to setup to run mozmill tests can be found here: https://developer.mozilla.org/en/Thunderbird/Thunderbird_MozMill_Testing That page currently does not provide much guidance on how to write tests, but there are extensive existing tests that should hopefully demonstrate the general idiom: http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/folder-display/

The fix looks ok to me (the end of the line should have a ';' though), and I don't think it's acceptable policy to require Dan (as his first patch) to write a test that's easily tens of times larger than the patch just to take a fix for an obvious oversight in the refactoring. Happy if he does of course ;)

I am not requiring Dan to write a test, but I am requiring that a fix for this problem have a test. The message display code, especially given the current multiplexed tab implementation, is not simple. Given that complexity, untested code is likely to break again. My position is that it's better to leave it broken until properly fixed (which means with a test) rather than apply a fix that removes the motivation for someone else to fix it with a test. Also, making changes to an unconstrained (by tests) feature is likely to have other side effects that may be worse. If the affected code were not something that is intimately related to already well-tested code with an already-existing test framework, I would be less of a hard-ass about this.

By the way, this happens on POP accounts as well. See bug #509401 (which is a dup of this one) for details. That bug also has some remarks on how to and how *not* to reproduce this bug, which might be helpful when writing test cases for it. Dan -- Thanks for the patch! It works for me on Linux too.

After some discussion with Andrew, we came to the conclusion that while an automated test would be ideal, we could probably live with a litmus test (which is just a description of how someone would manually test it) for Tb3. Dan, would you be willing to take a run at constructing this?

We may already have Litmus tests for this. I was thinking _Tsk_ might know/be able to check?

(In reply to comment #14) > We may already have Litmus tests for this. I was thinking _Tsk_ might know/be > able to check? We don't. Want me to add one ?

Yes, Ludovic, could you add a test for this? I'm going to land this patch, assuming it looks OK, so we can clear out our blocker list a bit.

fix checked in - we'd very much like a mozmill test in addition to the litmus test that Ludovic is going to add (or has added already...).

I still see this in Thunderbird 3.0 Beta 4. I guess I really just have to go back to v1.5 with its other issues, since the problem began in v2.0 and it makes TB unusable for any real work.

Running TB 3 beta 4 on Mac OS X Snow Leopard (10.6) and I can confirm this is fixed for me. I still had the problem in beta 3, but beta 4 fixed it. Thanks god. It has been confirmed as fixed by others as well. I guess you've tried the usual uninstall TB completely, reinstall a french beta 4 and so on? Resetting preferences? and so on?

I just did clean installs (fresh OS images) of 3.0b4 (English) on XP SP3 and Win7 RTM. Win7: No failure. XP: - No failure with it set to never mark messages as read. - Sometimes failed with it set to mark messages as read after a while. But not nearly as often as before. So I don't think the bug should be closed, since I can still repro it on XP. I'd be happy to use the "never mark as read" option, except for the fact that that even includes when you actually open a message instead of just previewing it. So that makes the option completely worthless. I want an option that only marks a message as read when it is fully opened - just never on preview. Is it really not completely obvious that that is what many people want?! BTW it looks like the bug was publicly introduced in the first 2.0.0.0 release. (1.5.0.14 works, 2.0.0.0 fails.)

I haven't checked this on XP, only Linux and MacOSX.

After restarting 3.0b4 a couple of times on XP, I'm not seeing the problem at all. So I guess it's just very random, but I think the bug is still out there and may just be hard to reproduce. I really hope that it's considered a bug that when "never mark as read" is selected, message aren't marked as read even when being fully opened. If it's just a matter of staying consistent with the language, then just change it to something like "Automatically mark previewed messages as read".

I highly doubt there's anything OS-specific about this bug.

(In reply to comment #23) > I really hope that it's considered a bug that when "never mark as read" is > selected, message aren't marked as read even when being fully opened. If it's > just a matter of staying consistent with the language, then just change it to > something like "Automatically mark previewed messages as read". It's not. We don't make a difference between reading it in the pane/tab/new window. If you read it, you read it.