Number of msgs in News Server is NOT reflected properly in pop-up window while downloading the headers. I beleive the messenger client reads the total number of headers from the newsrc file or the News server responds wrong numbers. Steps to reproduce: 1. Add "news" newsserver to the account. 2. Subscribe to "netscape.public.mozilla.mail-news" newsgroups. 3. When you click on this newsgroup to download the headers, a pop-up window shows up and reads "There are 1728 headers in the server. Do you want to download all or 500 headers". (Shown in check box with OK and Cancel button). 4. The reality is only 220 headers are present in the newsserver. The pop-up window should read "There are 220 headers in the server...". Build Date: 1/19/00 Linux commercial build.

for completeness: this problem is in 4.x with news://news/netscape.public.mozilla.mail-news they recently purged the old articles on news, news.mcom.com, and news.netscape.com (they are all the same machine)

4.x does the same thing. moving to m20, and I will investigate then.

4.x has the same problem - move to target milestone future

mass change of huang's news bugs to stephend.

Hi, I've noticed this on 1.7alpha also. From a brief investigation it seems to occur in this scenario. From telnetting to the news server: LIST ACTIVE some.news.group some.news.group 329201 318904 y Mozilla appears to interpret this to mean that there are 10297 (329201-318904) messages to download. However the LISTGROUP command returns the number of messages and the relavent message ID's. LISTGROUP some.news.group 211 articles follow 318904 322265 322352 322554 <snip> The RFC's (977 & 2980) do not state that the difference in message id's in the LIST output should be all available messages, nor that LISTGROUP should return a sequential list. It appears that mozilla should base its calculation on the number of headders to download based on the output of the LISTGROUP command and not LIST. Then retrieve the messages in the output from LISTGROUP and not just increment m_articleNumber based on the first article from LIST.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

I'm simplifying this bug's summary for easier future duping. This bug is essentially one of the two core, known, not-quite-a-bug newsgroup count bugs. What this is reflecting is that the news server is providing us a count estimate that does not reflect the holes produced by expired articles.

See workaround in bug 294754 comment #3 (in a bug which, by recursion, finally became duped to this one).

Joshua, could the bug 79130 be a dupe of this too?

After further thought, I've come to the conclusion that this and bug 79130 are the same issue. Although 79130 is newer, it is more discussion, and, for that reason, this will be a dupe of that one.