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 ***
2002021808 Bug 97598, an NT only bug, has been marked resolved. Reopening this, since it is not fixed.
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.
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?
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).
200 news1.atlantic.net on News Server (Typhoon v1.2.3)
Accident. Had the page open and reloading didn't set to platform previously set. Prolly a bugzilla bug.
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.
Created attachment 72126 [details] 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 email@example.com 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.
Bug 129574, rather.
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.
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. ***
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). firstname.lastname@example.org 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.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060404 SeaMonkey/1.0.1 This ancient bug still exists in SeaMonkey....
This bug is also present in Thunderbird 126.96.36.199 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.
Filter on "Nobody_NScomTLD_20080620"
This WFM on Linux 188.8.131.52pre 20080924. Does anyone still see a problem with message counts not reducing upon clicking the "remove all expired articles" link?
RESO WFM per comment 42 and lack of response to said question.
(In reply to Joshua Cranmer [:jcranmer] from comment #42) > This WFM on Linux 184.108.40.206pre 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).