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)
Thunderbird
Mail Window Front End
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird 3.0b2
People
(Reporter: bugs, Assigned: mkmelin)
References
Details
Attachments
(1 file, 1 obsolete file)
5.76 KB,
patch
|
jminta
:
review+
mkmelin
:
superreview+
|
Details | Diff | Splinter Review |
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•19 years ago
|
Whiteboard: DUPEME
Comment 1•18 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)
Hi, I can confirm this Bug for Linux. Thunderbird version 1.5.0.2 (20060420) Ubuntu Linux 2.6.15-21-k7
Comment 3•18 years ago
|
||
DUPEME is indicated, but what is the dup? Bug 291386?
Comment 4•18 years ago
|
||
not sure - I know Scott was working on something like this. I don't see a checkin, however...
Comment 5•18 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. :))
Comment 6•18 years ago
|
||
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•18 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.
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•18 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? :/
Comment 10•18 years ago
|
||
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•18 years ago
|
||
still in version 1.5.0.8 (20061025) Linux
Updated•17 years ago
|
QA Contact: front-end
Comment 12•16 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•16 years ago
|
||
Still in 2.0.0.12 (20080213) on Ubuntu Hoary 2.6.22-14-generic
Comment 14•16 years ago
|
||
version 3.0a1pre (2008050203) trunk Confirm
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•16 years ago
|
Assignee: mscott → nobody
Comment 15•16 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•15 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•15 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•15 years ago
|
||
Fix for thunderbird+seamonkey. (The ThreadPaneKeyPress change is just magic number cleanup.)
Attachment #355216 -
Flags: superreview?(neil)
Attachment #355216 -
Flags: review?(jminta)
Assignee | ||
Updated•15 years ago
|
Status: NEW → ASSIGNED
Updated•15 years ago
|
Attachment #355216 -
Flags: superreview?(neil) → superreview+
Comment 18•15 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•15 years ago
|
||
Carrying fws sr=neil
Attachment #355216 -
Attachment is obsolete: true
Attachment #355298 -
Flags: superreview+
Attachment #355298 -
Flags: review?(jminta)
Updated•15 years ago
|
Attachment #355298 -
Flags: review?(jminta) → review+
Comment 20•15 years ago
|
||
Comment on attachment 355298 [details] [diff] [review] proposed fix, v2 Awesome.
Assignee | ||
Comment 21•15 years ago
|
||
changeset: 1542:246e49f00ce6 http://hg.mozilla.org/comm-central/rev/246e49f00ce6 ->FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 22•15 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•15 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•15 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•15 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•15 years ago
|
||
Ah yes, I see that now.
Comment 27•15 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•