Closed Bug 115202 Opened 23 years ago Closed 16 years ago

Click here to remove all expired articles doesn't reduce message counts

Categories

(MailNews Core :: Networking, defect)

Product:
MailNews Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mrmazda, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: closeme 2008-12-14)

Attachments

(1 file)

Screencap of the Problem
54.64 KB, image/jpeg
Details 
2001121219, but not even close to new. This behavior is far older than I can
remember.

Clicking the link transfers focus to the browser, advancing to a blank browser
page. Meanwhile, in mailnews, the "expired" article remains selected with the
expiration message continued, and all "expired" message headers apparently
remain in the headers pane, unlike in Netscape 4, which advances the message
display to the next unexpired article and removes the headers of expired
messages from the headers pane.

What I don't understand is why when the newsgroup is selected that Mozilla
doesn't automatically display headers of only messages actually available from
the server. I realize the the selection causes the previous set of retrieved
headers to be redisplayed, but since it also looks for new ones to add to the
display, it should also be looking for expireds to remove. IOW, it shouldn't
need to be told to remove the expireds. It they aren't available, there is no
apparent purpose served by displaying those headers.

*** This bug has been marked as a duplicate of 97598 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Summary: Click here to remove all expired articles doesn't → Click here to remove all expired articles doesn't
verified dup.
Status: RESOLVED → VERIFIED
2002021808

Bug 97598, an NT only bug, has been marked resolved.

Reopening this, since it is not fixed.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Is there a platform-independent version of this bug in the database? I have been
witnessing the same behavior under all Linux builds since the Mxx versions
through the 2-18-2002 nightly.
OS: OS/2 → All
I have also confirmed this behavior in the MacOS 9 2/18/2002 nightly build. The
article window shows expired articles as read, but still shows the headers
without any apparent way to remove them. AS described, clicking on an expired
article opens a blank message window.
Mike - I know you're busy... When/if you get a chance, could you check and see
if removing expired articles works on OS/2, thanks?
Component: Mail Window Front End → Networking - General
QA Contact: esther → stephend
I don't understand how I can test this. What is an example of a newsgroup that 
expires articles quickly?

Also, in this bug are two people on other platforms have reported this.

The only way I could see this being Os/2 specific is if something in the 
expiration code is relying on time_t being an unsigned long.
Due to the reports from the Linux & Mac users, I doubt this has anything to due
with OS/2 in specific.

I don't know about all servers, but of the ones I have used, all expire alt
groups much faster than big 8 groups. In particular, the binary pictures groups
commonly expire in a matter of 48 hours or less. On the atlantic.net newsserver,
even non-binary articles very often expire in about 12 hours (broken, but I
haven't been able to get them to fix it).

Some groups I've seen very short expires in include alt.comp.periphs.mainboard.*
and alt.os.linux.*.
Confirming, setting OS/platform to All...  can anybody who experiences this
problem please give me their server version/type by doing 'telnet
news.server.com 119' (substitute 119 for the port you use).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
200 news1.atlantic.net on News Server (Typhoon v1.2.3)
Hardware: All → PC
Accident. Had the page open and reloading didn't set to platform previously set.
Prolly a bugzilla bug.
Hardware: PC → All
In case no one's checked yet, this bug is present in the latest Windows build as
well.
2002022816 OS/2

I just tested to see if the bug still exists. Behavior is now different. Focus
still shifts to a blank browser page when link is clicked, and the "click here
to remove expired articles" message remains in the Mailnews content pane, but
the expired messages were removed from the headers pane.

Focus should not leave Mailnews. Blank page should not be loaded in browser.
Content pane should be shifted to next message, or at the least, the "click her
to remove expired messages" link should be removed from view.
See bug 106267, which tracks all of the issues with Expired Article behavior.
Attached image Screencap of the Problem — 
For the skeptics. From 2002022816 for OS/2.
Confirming mrmazda's experience in 2002030108 for Linux. However, the "click
here to remove" link only appears if you are reading news in "paned" mode. If
you close the content pane and read news in a separate content window, this link
does not appear.

This is an improvement, although the ideal behavior would be for Moz to not show
expired articles in the first place  - maybe it could spawn a thread to remove
expired articles upon opening the mail/news panel, or when opening the newgroup?

Should I still be updating this bug or move to <A
HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=106267>10267</A>?
mrmazda - I believe this doesn't work for you (and others, which is why I
confirmed this bug).  What is
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=72126 supposed to show?
 Unless that article is a valid article, that behavior (showing the special HTML
message in place of the expired article) is currently currect.
s/currect/correct (type too fast)
The attachment shows a visited link in the message pane. This should not happen.
Expired message headers should automatically be removed by Mozilla when the
group is selected. If this is not possible, then at the very least Mozilla
should do like Netscape 4.x -> Once the link is clicked, the current (expired)
message should be cleared from the message pane, expired message headers should
be cleared from the headers pane, headers pane highlight should be on a
non-expired message, and content of selected message should be loaded in message
pane.
mrmazda - you must not have visited the tracking bug yet, which covers your
comments below:

------- Additional Comment #19 From mrmazda@atlantic.net 2002-03-03 05:08 -------

The attachment shows a visited link in the message pane. This should not happen.
Expired message headers should automatically be removed by Mozilla when the
group is selected.

See bug 95834

If this is not possible, then at the very least Mozilla
should do like Netscape 4.x -> Once the link is clicked, the current (expired)
message should be cleared from the message pane, expired message headers should
be cleared from the headers pane, headers pane highlight should be on a
non-expired message, and content of selected message should be loaded in message
pane.

See bug 72820 for the focus issue (browser window vs. 3 pane).

When Seth fixes those bugs, he will also address this comment (in your comment #0):

Meanwhile, in mailnews, the "expired" article remains selected with the
expiration message continued, and all "expired" message headers apparently
remain in the headers pane, unlike in Netscape 4, which advances the message
display to the next unexpired article and removes the headers of expired
messages from the headers pane.




Behavior has changed but remains fubar in 2002031416.

Instead of a blank page in browser opening when the link is clicked, a new
instance of mailnews opens. In the original mailnews instance, expired messages
are not removed. In the new instance, the preview pane turns blank, but the
frame still shows the same total and unread counts as the original. There
doesn't seem to be a way to determine whether the headers list is shorter or
not. The groups I go to to check this behavior have hundreds of messages.

In OS/2 2002031416, bug 130434 does not apply. Bug 129574 appears to overlap in
that a new window is unnecessarily spawned upon clicking a link to remove
expired message headers. However, the title of this bug appears to still apply
regardless of the partial duplication of bug 129574. No expired articles appear
to have been removed after link click.
Summary: Click here to remove all expired articles doesn't → Click here to remove all expired articles doesn't reduce message counts
2002033108

This may now be close to a worksforme. Hard to be sure. Before I clicked the
"click here to remove expired messages" in alt.os.linux.caldera, the counts on
the bottom frame were 32 unread, 34 total. After clicking the link and the
opening of the second mailnews window, the count changed to 32 unread, 31 total.
When I closed the second mailnews window, the count was also 32 unread, 31
total. I wonder about the math that allows unread to exceed total.
Still half fixed as of 2002041109. Total is reduced after clicking the link, but
unread stays the same (and exceeds the total). At least now a second mailnews
instance doesn't open after clicking the link.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419

As opposed to the previous comment, for me a new MailNews window opens.

pi
Yup, clicking link opens second instance again in 2002042108 OS/2 trunk. OTOH,
the result now shows fewer unread than total.
*** Bug 139167 has been marked as a duplicate of this bug. ***
Blocks: messagecount
Also problems for me (Windows NT 4.0 SP6a; Mozilla 1.0, build 2002053012).

A new mailnews-window opens when I click on "Click here to remove all expired
articles" . In the new window, all expired articles are still there (the total
count does not reduce). Clicking on the link to remove expired articles in the
new mailnews-window, opens again a new mailnews-window... (and this can be
repeated forever).
FWIW, I'm seeing this problem in OS/2 and Windows 98. Mozilla 1.0 (Build IDs are
different for different platforms). Get new window, nothing removed from list of
articles.

Jim
Let's try to sort this out.

People who see a new window open (message count does not update in both windows,
if one of the expired articles was unread):
pi using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/2002090311
Jim using OS/2 and Windows 98. Mozilla 1.0
Roy using (Windows NT 4.0 SP6a; Mozilla 1.0, build 2002053012).
mrmazda@ij.net using 2002042108 OS/2 trunk

How about current versions in OSes other than Linux?

People who only keep one window (also message count not updated):
Still someone?

pi
2002090708 OS/2 trunk

Reading in three pane, a new (three pane) mailnews window opens when the "click
here to removed expired articles" link is clicked <bug 129574>, with both total
and unread message counts updated as expected. When  I close the new mailnews
instance, the original also shows the updated counts as expected.  I found this
behavior with four different groups on two servers. Looks like we now have a
WORKSFORME.

I have had this problem with 1.2.1 builds on Windows ME as well as on W2000.
And now with the 1.3 version (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3) Gecko/20030312) the bug still pops up. It is quite anoying that another
window opens when clicking on the 'expire'-link, in stead of what (I think) it
is supposed to do, get rid of the expired articles, refresh/update the 'window'/
necessary 'items'.
So I hope it gets solved in the new versions.

I can confirm the problem is still there. Is there any chance to get it fixed in
the foreseeable future? Please.

Mozilla 1.4b, Windows2k SP3
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030505

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030612

bug still opening new mail-news window on "clear expired articles", and still
doesn't appear to actually clear any of the articles when clicked. the original
and newly spawned windows show the same articles / date ranges.
Blocks: 106267
Product: MailNews → Core
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1

This ancient bug still exists in SeaMonkey....
This bug is also present in Thunderbird 1.5.0.7 for Windows ME. Viewing in 3 pane wide screen classic screen.

The news core code is ignoring the servers sending the first available message index number when group is selected.  Only by a manual initiation of the code will Tbird process the new first message number.  In doing so it generates a new Tbird Window with an attendant time delay that blocks usage of Tbird till processes are finished. Expected behavior is auto process of current first message index number from server and deletion of expired headers from UA local headers list at the same time it adding new headers to headers pane display.
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: stephend → mailnews.networking
Product: Core → MailNews Core
This WFM on Linux 2.0.0.17pre 20080924.

Does anyone still see a problem with message counts not reducing upon clicking the "remove all expired articles" link?
Whiteboard: closeme 2008-12-14
RESO WFM per comment 42 and lack of response to said question.
Status: NEW → RESOLVED
Closed: 23 years ago → 16 years ago
Resolution: --- → WORKSFORME
(In reply to Joshua Cranmer [:jcranmer] from comment #42)
> This WFM on Linux 2.0.0.17pre 20080924.
Doesn't WFM on Windows
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120420 Thunderbird/12.0

> Does anyone still see a problem with message counts not reducing upon
> clicking the "remove all expired articles" link?

Actually, yes: When I click on the link, nothing happens and the expired messages aren't deleted.
(In reply to Christian Stadler from comment #44)
> > Does anyone still see a problem with message counts not reducing upon
> > clicking the "remove all expired articles" link?
> 
> Actually, yes: When I click on the link, nothing happens and the expired
> messages aren't deleted.

Bug 727951--that's a separate issue that will be fixed in TB 13.
What rv does TB 13 mean? This is a core bug filed against Mozilla Suite. I only use Suite.
SM 2.10 (current comm-beta).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: