514876 - Navigating from standalone message window fails to mark messages as read

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Robert Roessler]

When viewing mail messages in a separate window, navigating to the "next unread" message works, but leaves visited messages as "unread".  The expected (and historical) behavior is that any read message will in fact be marked as "read".

This started when the TabbedMail stuff landed in the 2.0b2pre (now 2.0pre) builds.

Note that this works properly from a separate *tab*, but not from a *window*.

Comment 1

[Robert Roessler]

I bumped this to "major" because a key part of the mail reading functionality has been broken... messages that are read not being marked as such makes it harder to, well, keep track of what has been read vs what has not. ;)

If this adjustment is inappropriate, point me to the relevant Bugzilla "style guide" section so that I will know why I shouldn't attempt "Importance" adjustments in the future.

Comment 2

[chicagolovr]

Messages won't mark as read as you have described, plus if you close the message the cursor or highlight moves to another previous message.  Which may explain why when I hit reply to a newsgroup message it often opens *the previous* message... not the one I was in... and wanted to reply to.  Hope this makes sense, and it probably needs another bug filed... not sure.

Comment 3

[chicagolovr]

I think I should have said above, I'm using XP and no add ons... also it crashed on me this morning when I was trying to search for "mark messages" in the Mozilla SM newsgroup... so a report was filed.

Comment 5

[Robert Roessler]

Bug 516467 includes useful information on this problem, including comments on what may be the underlying cause.

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #5)
> Bug 516467 includes useful information on this problem, including comments on
> what may be the underlying cause.

I was about to say we need a regression range since in that other bug I noted that this was reported to work as expected in b1. Reading comment 0 you state that this started to fail with the landing of tabmail. Is that a fact or a guess?

Comment 7

[Robert Roessler]

Technically, it would be a guess (without an explicit regression range).

I will now attempt to nail it down further to one of the nightly builds.

Comment 8

[Robert Roessler]

SM2b2pre 20090831005004 WORKS
SM2b2pre 20090901010201 FAILS

These are the nightly builds I was using... note that on 8/31, BOTH

http://hg.mozilla.org/comm-central/rev/7b0ece4c9b53

and

http://hg.mozilla.org/comm-central/rev/0c7943df7694

went in in time for the 9/01 nightly "comm-1.9.1" build - but the latter is merely a "bustage fix", not the main "Tabbed Mail" checkin.

So I wasn't kidding about the "when", but this is clearly more rigorous (although we are talking a large checkin). ;)

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

The code line which triggered marking the message as read was in messageWindow.js, function LoadMessageByMsgKey(): gDBView.loadMessageByViewIndex(viewIndex);
From there it continues in C++ land where I don't exactly feel at home. I guess somewhere an observer was notified (and maybe still is, only found displayMessageChanged) which triggered the actual mark as read with optional timeout which is in mailWindowOverlay.js function OnMsgLoaded().

Comment 10

[Karsten Düsterloh]

Attachment: guard tabmail calls

Code in commandglue.js is meant to handle both main and standalone window, but the latter doesn't have a tabmail object...

Comment 12

[Karsten Düsterloh]

Pushed as <http://hg.mozilla.org/comm-central/rev/f4fb62ef4baf>.