If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in Thunderbird 3.0b2

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
12 years ago
7 years ago

People

(Reporter: Stefan Geisseler, Assigned: Magnus Melin)

Tracking

Trunk
Thunderbird 3.0b2
Bug Flags:
blocking-thunderbird3 -
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

5.76 KB, patch
Joey Minta
: review+
Magnus Melin
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
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

Updated

12 years ago
Whiteboard: DUPEME

Comment 1

12 years ago
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)

Comment 2

12 years ago
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?

Comment 4

12 years ago
not sure - I know Scott was working on something like this. I don't see a checkin, however...

Comment 5

11 years ago
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?

Comment 7

11 years ago
(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.

Comment 8

11 years ago
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?

Comment 9

11 years ago
(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

Comment 11

11 years ago
still in 
version 1.5.0.8 (20061025) Linux
QA Contact: front-end

Comment 12

10 years ago
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

Comment 13

10 years ago
Still in 
2.0.0.12 (20080213) on Ubuntu Hoary 2.6.22-14-generic
Keywords: qawanted

Comment 14

10 years ago
version 3.0a1pre (2008050203) trunk Confirm
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

9 years ago
Assignee: mscott → nobody

Comment 15

9 years ago
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?
(Assignee)

Comment 16

9 years ago
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
(Assignee)

Updated

9 years ago
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
(Assignee)

Comment 17

9 years ago
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)
Attachment #355216 - Flags: review?(jminta)
(Assignee)

Updated

9 years ago
Status: NEW → ASSIGNED

Updated

9 years ago
Attachment #355216 - Flags: superreview?(neil) → superreview+

Comment 18

9 years ago
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-
(Assignee)

Comment 19

9 years ago
Created attachment 355298 [details] [diff] [review]
proposed fix, v2

Carrying fws sr=neil
Attachment #355216 - Attachment is obsolete: true
Attachment #355298 - Flags: superreview+
Attachment #355298 - Flags: review?(jminta)

Updated

9 years ago
Attachment #355298 - Flags: review?(jminta) → review+

Comment 20

9 years ago
Comment on attachment 355298 [details] [diff] [review]
proposed fix, v2

Awesome.
(Assignee)

Comment 21

9 years ago
changeset:   1542:246e49f00ce6
http://hg.mozilla.org/comm-central/rev/246e49f00ce6

->FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 22

9 years ago
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.
(Assignee)

Comment 23

9 years ago
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.

Comment 24

9 years ago
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.

Comment 25

9 years ago
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.
(Assignee)

Comment 26

9 years ago
Ah yes, I see that now.

Comment 27

9 years ago
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.

Updated

9 years ago
Depends on: 472137
You need to log in before you can comment on or make changes to this bug.