376171 - Reading new newsgroup or mail messages is now a pain

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 365049.

STEPS TO REPRODUCE:

1)  Open mailnews
2)  Read some newsgroup or mail folder (call it A)
3)  Switch to a different newsgroup or mail folder (calls it B)
4)  Wait for a new mail or news messages in A (e.g. send yourself an e-mail)
5)  Once the messages arrive, switch back to folder A

ACTUAL RESULTS:  The last message you read is at the bottom of the threadpane.  The new messages are out of sight and you have to scroll to them to see them.  This is particularly bad if the last message you looked at was an old message -- you may have to do a LOT of scrolling to get to the new messages.

OLD BEHAVIOR:  The first new message is at the bottom of the threadpane, so you can start reading your new mail right away.

EXPECTED RESULTS (desired behavior):  The first new message is at the top of the threadpane, so you can start reading your new mail right away and see as much of it as possible.

Comment 1

[Karsten Düsterloh]

The respective code is here: <http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/base/resources/content/msgMail3PaneWindow.js#113>

The logic behind this is that explicitly remembering the last selected message should overrule incoming new messages, so that you can continue reading mail from where you last stopped, even if new mails are coming in. 

You get the behaviour you requested by setting mailnews.remember_selected_message to false (respectively turning that off in the preferences).

Comment 2

[Boris Zbarsky [:bzbarsky]]

But that also affects the case when there is no new mail, and in that case I _do_ want to come back to the last message I saw.

Comment 3

[Karsten Düsterloh]

Attachment: prioritize new over remembered again

Given that those who have turned on "remember last selected" and want that to override "scroll to new" obviously don't want the latter (since we almost always do have a last selected message), they're probably able to set mailnews.scroll_to_new_message to false.
Hence keeping the traditional checking order seems reasonable.

Comment 4

[[e-mail]]

Comment on attachment 260293 [details] [diff] [review]
prioritize new over remembered again

>+  var scrolled = pref.getBoolPref("mailnews.scroll_to_new_message") &&
>+               ScrollToMessage(nsMsgNavigationType.firstNew, true, false /* selectMessage */);
You might want to tweak the indent here.

Comment 5

[Robert Kaiser]

Comment on attachment 260293 [details] [diff] [review]
prioritize new over remembered again

a=me for 1.1.2

Comment 6

[Karsten Düsterloh]

Landed on trunk and MOZILLA_1_8_BRANCH.
Forgot the indent on trunk, though. :|

Comment 7

[Worcester12345]

(In reply to comment #0)
> This is a regression from bug 365049.
> 
> STEPS TO REPRODUCE:
> 
> 1)  Open mailnews
> 2)  Read some newsgroup or mail folder (call it A)
> 3)  Switch to a different newsgroup or mail folder (calls it B)
> 4)  Wait for a new mail or news messages in A (e.g. send yourself an e-mail)
> 5)  Once the messages arrive, switch back to folder A
> 
> ACTUAL RESULTS:  The last message you read is at the bottom of the threadpane. 
> The new messages are out of sight and you have to scroll to them to see them. 
> This is particularly bad if the last message you looked at was an old message
> -- you may have to do a LOT of scrolling to get to the new messages.
> 
> OLD BEHAVIOR:  The first new message is at the bottom of the threadpane, so you
> can start reading your new mail right away.
> 
> EXPECTED RESULTS (desired behavior):  The first new message is at the top of
> the threadpane, so you can start reading your new mail right away and see as
> much of it as possible.
> 
Seeing these exact same symptoms in Thunderbird nightly 2.0 builds. Should "Product" be "Core"? Thanks.

Comment 8

[Boris Zbarsky [:bzbarsky]]

There are no relevant components in the Core product, unfortunately.  But I do think this code is shared by Tbird...

Comment 9

[Karsten Düsterloh]

(In reply to comment #7)
> Seeing these exact same symptoms in Thunderbird nightly 2.0 builds.

This would be strange, because I did bug 365049 for SM only and thus partly undid it here for SM only also. TB never changed the order of "new" vs. "remembered".

(In reply to comment #8)
> There are no relevant components in the Core product, unfortunately.

Somehow, Bugzilla reorgs always seem to take ages... :|
There's even a bug for having TB flags for SM bugs (bug 361626), but that didn't went anywhere yet, too.

Usually, we use Core/MailNews:Backend for shared bugs, as wrong as it may be.

> But I do think this code is shared by Tbird...

No. TB has its own copy of this file.
In fact, only few frontend files are shared still, mainly address book and views.