Closed Bug 313227 Opened 19 years ago Closed 15 years ago

wait x seconds before marking message as read affects wrong message if quick-keying through the message list after timer started

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: bugs, Assigned: mkmelin)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Whiteboard: DUPEME
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 1.5.0.2 (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 1.5.0.5 (20060719)
Firefox also produces other version info: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
(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 1.5.0.7 (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 1.5.0.7 (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
Whiteboard: DUPEME
Version: unspecified → 1.5
still in 
version 1.5.0.8 (20061025) Linux
QA Contact: front-end
CONFIRMED!!!

I saw the same behavior, and I always can reproduce it.

Using version 2.0.0.12 (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 
2.0.0.12 (20080213) on Ubuntu Hoary 2.6.22-14-generic
Keywords: qawanted
version 3.0a1pre (2008050203) trunk Confirm
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: mscott → nobody
And its still there
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
Flags: blocking-thunderbird3?
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
Keywords: qawanted
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
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
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
Attached patch proposed fix (obsolete) — Splinter Review
Fix for thunderbird+seamonkey.

(The ThreadPaneKeyPress change is just magic number cleanup.)
Attachment #355216 - Flags: superreview?(neil)
Attachment #355216 - Flags: review?(jminta)
Status: NEW → ASSIGNED
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-
Attached patch proposed fix, v2Splinter Review
Carrying fws sr=neil
Attachment #355216 - Attachment is obsolete: true
Attachment #355298 - Flags: superreview+
Attachment #355298 - Flags: review?(jminta)
Attachment #355298 - Flags: review?(jminta) → review+
Comment on attachment 355298 [details] [diff] [review]
proposed fix, v2

Awesome.
changeset:   1542:246e49f00ce6
http://hg.mozilla.org/comm-central/rev/246e49f00ce6

->FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 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.
Depends on: 472137
You need to log in before you can comment on or make changes to this bug.