Closed Bug 102804 Opened 23 years ago Closed 16 years ago

New newsgroups don't show up in subscription window

Categories

(MailNews Core :: Networking: NNTP, defect, P3)

x86
All
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: samir_bugzilla, Unassigned)

References

Details

Build
=====
Win2K 20011001 0.9.4 branch

Problem
=======
When I launch the subscription window -- say by clicking on the "Subscribe..."
context menu item of a newsserver account I have already added to my mozilla
installation -- newsgroups that have been added to the newsserver since the time
I created the account do not show up.  

Steps to reproduce
==================
(1) Create a newsserver account and subscribe to a group (using the Edit|Mail &
Newsgroup Account Settings window and clicking on the New Account button).
(2) Now right click on the newsserver account name that you just added and
select the "Subscribe..." item to bring up the subscription window.
(3) You'll see a few newsgroups: take note of them.
(4) Add a new newsgroup to the newsserver: say "foo."
(5) Repeat step (2) in your mozilla installation.

Actual results
==============
You will not see the new newsgroup, "foo," in the subscription window.

Expected results
================
The client fetched a list of all newsgroups available on the newsserver and
updated the list/database used to generate the trees in the subscription window
so users can see and subscribe to these newsgroups without having to click the
"Refresh" button on the subscription window.  You should be able to see the new
newsgroup, "foo," now.

Usablility datapoint
====================
As one user of this interface my vote is that having to press the "Refresh"
button everytime the subscription window comes up is counter-intuitive and a
task that can be automated (even if it is done in the background by some
prefetching mechanism during periods of dormant/no network activity if it is
considered a performance issue).
I've been reading Usenet news for 10+ years, but it never occurred to me that my
Subscribe dialog was using group lists that were 6+ months old, without even
notifying me that the list was old and there were new groups not listed.  I
assumed the 'refresh' button was for updating any contents that may have changed
since the list was displayed, probably because that is the way refresh is used
in other apps like IE.  Such usage heavily implies that the list was fresh when
displayed, much as we use 'reload'.  A cheap bandaid fix for this might be to
change the wording to "Check for new groups" or some other command other
newsreaders use, to make it clear that it must be used in order to see the
current list. However, I think the reasonable expectation of most users is that
what is displayed is what is available.  Why would users ever want to see a list
of groups that is incomplete and out of date anyway?
cc jglick for UE input.
Nominating for mozilla0.9.6.
Keywords: mozilla0.9.6
I think Trudelle's point is valid. I would guess most users expect that opening 
a new subscribe dialog presents the most up to date information. 
What kind of perf hit is there for checking for new newsgroups each time the
subscribe dialog is opened?  If it's noticeable, I'd agree with the idea of
changing the text.
Keywords: nsbeta1
I recall in 4.x it was an annoying user experience when the dialog came up
because of the perf hit -- it looked like it was getting an updated list of
newsgroups.  Not sure if we can now be more efficient.  Another idea is to do
some sort of background update of the list of newsgroups.

Does the NNTP RFC specify a last-modified-date type header analogous to HTTP
that tells us when the last date any new newsgroups were added?  We could store
this every time we update and then compare when bringing up this dialog.  Then
the perf hit would not be as bad one would think (if we made some assumptions
about how often newsgroups were added to newsservers for our target audience usage).
http://www.newsreaders.com/misc/twpierce/news/rfc977.html

Section 3.7 NEWGROUPS

 (client asks for new newsgroups since April 3, 1985)

A client issues the LIST command
C:      NEWGROUPS 850403 020000

   S:      231 New newsgroups since 03/04/85 02:00:00 follow
   S:      net.music.gdead
   S:      net.games.sources
   S:      .

   C:      GROUP net.music.gdead
   S:      211 0 1 1 net.music.gdead Newsgroup selected
           (there are no articles in that newsgroup, and
           the first and last article numbers should be ignored)

   C:      QUIT
   S:      205 Imaginary Institute news server ceasing service.  Bye!

 Please note that an empty list (i.e., the text body returned by this command
consists only of the terminating period) is a possible valid response, and
indicates that there are currently no new newsgroups.
Keywords: nsbeta1nsbeta1+
Priority: -- → P3

*** This bug has been marked as a duplicate of 40260 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
This isn't really the same as bug 40260 since that bug is asking for a ``New''
newsgroups tab that users must explicitly click to get new newsgroups.  This bug
is about getting new newsgroups implicitly upon opening the subscribe dialog in
the event that the newsserver's list of newsgoups has been downloaded before. 
But that solution might be a good trade-off between performance and having the
functionality.  The mailnews folks have made their call by marking this  bug
nsbeta1+.  
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 122274
Status: REOPENED → ASSIGNED
Keywords: nsbeta1+nsbeta1-
I have a problem with this RFE. NS4 behaviour (bug 40260) is for me a better
solution as an end user than what is proposed here because it allows me to know
WHAT are the new newsgroups available on my server. If we do a silent download
of new forums available on the server, how will I know that there are new groups
I could subscribe to ? This is precisely the purpose of the Refresh button in
ns4, to tell me what are the new forums I can subscribe to. Actually, I still
have NS4 installed on my computer precisely for this reason, I fire it up once a
week and check what new groups I am likely to subscribe to.
Pascal,
Point taken.  How about at least having some notion (UI indicator) that new
newsgroups exist?  Then users can choose to download the refrreshed list and see
which ones are in fact new.  The issue I was raising was that users don't know
that new newsgroups exist and may not think to refresh their lists.
When I execute a refresh, I see no changes - until I scroll all the way to the
bottom and see new groups out of alphabetical order at the end.
OS: Windows 2000 → All
*** Bug 238116 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
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
Status: ASSIGNED → NEW
QA Contact: stephend → networking.news
Fixed on Linux as of Thunderbird 3.0a2pre.

If you hit refresh, the new groups appear, in correct alphabetical order. Selecting New Groups satisfies the UI indicator, and automatically refreshes. Graceful handling too of NNTP errors there...
Status: NEW → RESOLVED
Closed: 23 years ago16 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.