210210 - List window not refreshed when new newsposts arrive

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Tom Sommer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030621 Mozilla Firebird/0.6
Build Identifier: 

The message list is not refreshed when new newsposts arrive. 
When having a NEWS folder selected (like netscape.public.mozilla.general) and
new posts arrive in this newsgroup (folder gets marked with bold and a (x) is
appended), the message list is not refreshed. You cannot see the new posts.

One has to click away from the folder and then back again (forcing a window
refresh) to view any new messages.

Reproducible: Always

Steps to Reproduce:
1. Select any newsgroup
2. Wait for it to be marked bold, indicating new messages has arrived in the group
3. Look for the new messages in the message list

Actual Results:  
No new posts/messages are shown in the message-list

Expected Results:  
The message list should display the newly received newsposts (automatically
refreshing the message-list)

I have heard reports that this also affects IMAP account, but I can not confirm this

Comment 1

[Tom Sommer]

Moving to Thunderbird, since that is infact where I can reproduce this.
And where this bug is most likely to get fixed

Comment 2

[Scott MacGregor]

no this should stay in mozilla/mail unless the problem is unique to thunderbird.

Comment 3

[Tom Sommer]

I do not have Mozilla MailNews... Help to testing in MailNews is appreciated

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I don't see this as a missing feature. Who likes it, when new postings are
inserted automatically within the Threadpane? 

Only one example: 
You haven't read a group for a long time and want to catch up it now. So you
check every Thread (but not all postings - thread stays bold). Meanwhile new
postings arrive and will be inserted inside threads you already checked. Will
you see the new postings? No... they are hard to find without changing the
sorting mode into `date'.

The count you see inside the folderpane is only a check on the NEWS-Server.
Mozilla/TB doesn't download the header at this point. The download of them
appears when you select "Get Messages for Account" within the contextmenu or
switching the groups.

In my opinion the behavior is right. New postings should not be inserted
automatically but manually or during startup.

Comment 5

[Rob Hudson]

this bug WFM on Mozilla Thunderbird 0.4 (20031206) and also in mozilla 1.
I'm not sure I understand the bug. With my news account I have to right click
and then go get messages for this account to check for new messages, they don't
appear automatically.....
Please can you confirm if you still get this bug?
I also think it should be moved to mail/news

Comment 6

[Rob Hudson]

As a follow up to this i can confirm it in mozilla 1.6b. So it should be moved
to mail/news.
I'm not convinced it is a bug and should possibly be RFE, see post #4.

Comment 7

[Joe Infla]

confirming; moving to mailnews as it's been reported in both products. 
downgrading severity (workaround available).

Comment 8

[Oscar Manuel Gómez Senovilla]

I'm not sure it this happened in 1.5 (I don't think so), but it seems that
something has broken in 1.6. I can confirm the bug, but haven't tried if it has
been fixed in 1.7.

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420