User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051020 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051020 Firefox/1.5 If you select a message and move fast enough through other unread messages with up/down keys, another message will be marked as read. Reproducible: Always Steps to Reproduce: 1. Set wait 3 seconds befor marking messages as read in Options => Advanced => General 2. Take several unread messages among each other (you can take read messages and mark them as unread for this test) 3. Click on one of the unread messages, wait until the body data is loaded 4. Move up/down your current position with up/down keys fast (several times per second) in a way that message bodies aren't loaded/shown Actual Results: The message selected after 3 seconds (it doesn't mather on which unread one you are at this moment) will be marked as read Expected Results: The message shouldn't be marked as read when you moved to another mail. Move up/down your current position with up/down keys slowly (every second) in a way that message bodies are loaded/shown => everythings seems to be ok
Can I confirm this somehow? I just wanted to report it but then found this bug. Not sure if it's a dupe, it's the first one I found. Thunderbird Version: 1.5 (I'm not allowed to change it)
Hi, I can confirm this Bug for Linux. Thunderbird version 184.108.40.206 (20060420) Ubuntu Linux 2.6.15-21-k7
DUPEME is indicated, but what is the dup? Bug 291386?
not sure - I know Scott was working on something like this. I don't see a checkin, however...
I can confirm this bug: Thunderbird version 220.127.116.11 (20060719) Firefox also produces other version info: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20060728 Firefox/22.214.171.124 (I'm too lazy to find the full version report in Thunderbird when Firefox's 'about:' finds it so quickly. :))
Hellday@gmx.dem, Yves, do you see this with a trunk build? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ mike cow', what bug did you have in mind to dup against?
(In reply to comment #6) > mike cow', what bug did you have in mind to dup against? Maybe bug 233027? But the fix for that was in for 1.5, it looks like.
Yep, the bug still is in the latest trunk. https://bugzilla.mozilla.org/show_bug.cgi?id=233027#c14 says the read timer should be cleared in some additional places. So I guess it should be cleared after changing the cursor (up / down keys). Can someone now confirm this bug?
(In reply to comment #8) > Can someone now confirm this bug? I can confirm the bug - now I'm in Linux - :) Thunderbird version 126.96.36.199 (20060922), Kubuntu version 2.6.15-27-386 There's only one radio box here saying "Leave as UNCONFIRMED". I guess I don't have the privileges required to confirm? :/
unable to recreate this on windows version 3 alpha 1 (20061017) and version 188.8.131.52 (20060909) (In reply to comment #9) > There's only one radio box here saying "Leave as UNCONFIRMED". > I guess I don't have the privileges required to confirm? :/ requires canconfirm privileges
Severity: major → normal
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → 1.5
still in version 184.108.40.206 (20061025) Linux
CONFIRMED!!! I saw the same behavior, and I always can reproduce it. Using version 220.127.116.11 (20080213) over WINXPSP2. I can attach a screencapture movie, if needed. Scenario: I set my "wait x seconds before marking a message as read" to 5. I have 3 messages, the first one read, and the other 2, unread. The first one is selected. Then I move with the down arrow to the 2nd message. If I stay there for 5 seconds or more, this one will be marked as read. PERFECT. But if I move to the third message before five seconds (lets day 4.8 seconds) when I become able to read the message in the below pane, at the same time this 3th message gets "read" state, and the previous one (which I read for 4.8 seconds) is still unread (what is correct). When you move down, the timer is not being refreshed and restarted. It could be an issue of adding more resets to that timer, or even we can be facing timming issues. Since I found this, I posted here. If I need to open a new one, please let me know. I think that is the same problem, just differently experienced. Hope this helps. Kind regards, Marco Lovato
Still in 18.104.22.168 (20080213) on Ubuntu Hoary 2.6.22-14-generic
version 3.0a1pre (2008050203) trunk Confirm
Status: UNCONFIRMED → NEW
Ever confirmed: true
And its still there Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
Ok, so we can either A) cancel the timer when the navigation or B) keep track of the message the timer was started for. I think I like B better; with A the message won't get auto marked as read at all if you come back to it later during that up-down quick-keying session. And, you are in fact viewing the message that time since message display isn't changing.
Assignee: nobody → mkmelin+mozilla
Summary: wait x seconds before marking message as read affects not only the message where the timer was started → wait x seconds before marking message as read affects affects wrong message if quick-keying through the message list after timer started
Target Milestone: --- → Thunderbird 3.0b2
Version: 1.5 → Trunk
Summary: wait x seconds before marking message as read affects affects wrong message if quick-keying through the message list after timer started → wait x seconds before marking message as read affects wrong message if quick-keying through the message list after timer started
Created attachment 355216 [details] [diff] [review] proposed fix Fix for thunderbird+seamonkey. (The ThreadPaneKeyPress change is just magic number cleanup.)
Attachment #355216 - Flags: superreview?(neil) → superreview+
Comment on attachment 355216 [details] [diff] [review] proposed fix } +function MarkMessageAsRead(msgHdr) Need some doxygen documentation for the function and its parameter. if (markReadDelayTime == 0) MarkCurrentMessageAsRead(); else - gMarkViewedMessageAsReadTimer = setTimeout(MarkCurrentMessageAsRead, - markReadDelayTime * 1000); + gMarkViewedMessageAsReadTimer = setTimeout(MarkMessageAsRead, + markReadDelayTime * 1000, + msgHdr); } else // standalone msg window MarkCurrentMessageAsRead(); It seems weird to have two functions (MarkCurrentMessageAsRead and MarkMessageAsRead) that essentially do the same thing through 2 very different code-paths. I'd really prefer to move the old callers to this new function too, since you have the msghdr available for them as well.
Attachment #355216 - Flags: review?(jminta) → review-
Created attachment 355298 [details] [diff] [review] proposed fix, v2 Carrying fws sr=neil
changeset: 1542:246e49f00ce6 http://hg.mozilla.org/comm-central/rev/246e49f00ce6 ->FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
something has very recently broken the handling of marking messages read in cross-folder saved searches - the line in the thread pane is not invalidated - my first suspicion would be this patch.
Don't know what you mean by the line not getting invalidated, but marking read in cross-folder saved-searches seem to work fine over here with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090105 Lightning/1.0pre Shredder/3.0b2pre.
I meant that doing things like next unread, which takes you to the next unread message, loads it, and marks it read (I have no delay set), leaves the message header displayed as unread and new, until I move the mouse over it, which causes a repaint of that row. This happened with debug builds on both windows and mac. I'll dig into it - perhaps it's a build issue.
The fact that we're no longer going through the view to mark the message read is most likely the cause. These are pop3 messages. Perhaps the cross-folder saved search isn't invalidating the row when someone else marks the header read, which of course it should. There might even be a bug open on that.
Ah yes, I see that now.
I have a fix for this - I'll look through my bug list and see if I have an open bug on the underlying issue.
You need to log in before you can comment on or make changes to this bug.