73296 - Collapse All + Expand buttons are missing from the Subscribe window.

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[[e-mail] (gone - use [e-mail] instead)]

Summary: Collapse All + Expand buttons are missing from the Subscribe window.

Build ID: today's, all platforms.

Steps to Reproduce:

1.  Launch newsgroups or mail.
2.  Open the Subscribe window via selecting an account and doing File |
Subscribe or right clicking and selecting Subscribe from the context menu at the
server level.
3.  This brings up the Subscribe window.

Expected Results:

The Subscribe window should have Collapse All + Expand buttons when expanded or
collapsed hierarchies, respectively, are present.

Actual Results:

Neither button is available.

This is 4.x parity. (Note, couldn't find a bug searching my bug list or the
phrase "Collapse All" in bugzilla.

Comment 1

[Jay Smith]

Mozilla 1.2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
on Red Hat 8
Just installed.

Problem still exists. 

(We are leaving Netscape 4.76 on Red Hat linux 6.x, but this bug could prevent
us from using Mozilla on RH 8.)

**Huge** problem for our organization. We have more than a hundred folders in a
deep structure (up to 8 levels) containing well over 1000 mailboxes -- and
growing very fast -- every customer gets a mailbox.

This bug is _serious_ because it is related to the bug #167107 "can only see two
IMAP folder levels two folders deep if have selected 'show non-subscribed
folders' in preferences".

This is a double-whammy: Because the great feature 'show non-subscribed folders'
does not work for imap users, that _forces_ each and every user to subscribe
often.  In our organization, several people are adding several mailboxes every
day and all users need to be able to get at them within a day or two of the
mailboxes being added.

Without an Open All button and/or 'selected a range of folders and click an open
folders button', that means that virtually every day each of our users will have
to subscribe (because of bug #167107) AND have to manually open (in the
Subscribe) 100+ folders (because of this bug #73296) to be sure that they have
seen everything that they need to subscribe to.

Ouch! That is going to cost us a lot of money/labor/time if we choose to use
Mozilla -- this will affect our selection decision.

Comment 2

[(not reading, please use [e-mail] instead)]

adding jglick for UI consideration.

I can't remember if we omitted these buttons on purpose.  

(outlook express doesn't have them, so we might have decided to drop them to
simplify the dialog)

Comment 3

[Jay Smith]

This missing feature is such a huge problem because it is in combination with
bug http://bugzilla.mozilla.org/show_bug.cgi?id=167107

In private correspondence the issue of importance of a bug like this came up. I
would like to use this case to illustrate why a bug (missing feature) such as
this -- which some people may consider to be esoteric -- is mission critical for
some organizations.  Unfortunately, the bugzilla.mozilla system does not seem to
have a method for recognizing the differences in priority in such a situation...
Thus an "esoteric" feature/bug that affects a few "normal" users gets ranked the
same as an "esoteric" feature/bug that affects a few "power/business/enterprise"
users -- but they each have hundreds, thousands, or even tens of thousands of
desktops!

There are features/bugs that are much more likely to be used and _required_
by businesses/enterprises that are make-or-break for power-use
organizations.  To the ordinary user or the individual developer, some of
these (like "my" problems with Subscribe) may seem esoteric.  However, if
mozilla wants to compete with M$ and the like and land on the business
desktop, mozilla must realize that features _required_ by enterprises
_have_ to work -- we are talking about REAL MONEY and real time.

In my small organization, I estimate that the subscribe problems (the
_combination_ of #167107 and #73296) will COST 15 MINUTES PER DAY, PER USER.
Here in North Carolina labor may be cheaper, but that is still going to
COST (simply the labor cost including payroll taxes and benefits figured on
a per-hour basis) about $1000 PER USER, PER YEAR.  I certainly cannot
afford that and I cannot imagine a larger organization tolerating it for a
nanosecond.

On a more individual basis, can you imagine how frustrating it would be to
manually click open hundreds of Subscribe folder levels every day?  I think
I would have a mutiny on my hands.

So, while this type of problem does not cause the product to crash, etc.,
it prevents it from being taken into use in larger organizations.  Mail is
an absolutely key component -- few organizations are going to use Mozilla
for browsing and something else for mail.  It is generally all or nothing.
In other words, if mail is not efficient in organizations, then M$ wins
again.

Remember that M$ has had so many victories because they focus on features, not
elegance of code.  To beat them you need _both_ features and better code.

Comment 4

[jglick]

>I can't remember if we omitted these buttons on purpose. 

Doesn't appear to be any reason, probably just time/resource constraints. OK 
with me to add this functionality.

Comment 5

[Jay Smith]

Have just upgraded to Mozilla 1.6 on Linux Red Hat 8.

The problem still exists and is incredibly frustrating.  Because we have over
2000 mail boxes and several users that need to be subscribed to most of them, it
is extremely time consuming to go through the subscribe process.

The possible workaround of using the preferences option to show all #shared IMAP
folders (thus not using subscribe) is NOT productive because there is a HUGE
PERFORMANCE HIT every time any directory is opened -- Mozilla chugs through all
the folders in it each time (our directories have 1-100 mail boxes in each).

Comment 6

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

Why we don't use the same behavior like within the thread pane? There you can
expand the whole folder by pressing '*' and collapse with '\'. Perhaps we don't
need a button for that for the first time - just having this neccessary feature.
It's very painful to get the right group every time.

Comment 7

[Jay Smith]

The suggestion of.....

> Why we don't use the same behavior like within the thread pane? 
> There you can expand the whole folder by pressing '*' and collapse 
> with '\'. Perhaps we don't need a button for that for the first 
> time - just having this neccessary feature.

would be okay as long as the dialog box had clear instructions to this effect.
To have this behavior without clear instructions is setting up for failure
because only those in the know would know.  I have been using Mozilla for a
couple of years and I did not not know this trick.

That being the case, let's just add a button.  Is that so hard?  Am I missing
something?

Jay

Comment 8

[Jay Smith]

I have just upgraded to 1.7.2 and disappointed to discover that this has still
not been addressed.

For heavy IMAP users, this is a really big deal.  We have thousands of IMAP
folders (nested as many as 8 levels deep) and it is a royal pain to have to
click AT LEAST A COUPLE HUNDRED TIMES to open everything up to "expose" the
mailboxes for subscribing ----- FOR EACH USER!  Argh!

Jay

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

I agree that it's bad for a certain group of (heavy) users.

Comment 10

[[e-mail]]

Attachment: Make Expand All work on my news server

Comment 11

[[e-mail]]

Comment on attachment 158005 [details] [diff] [review]
Make Expand All work on my news server

ExpandAll crashed trying to expand
alt.0.0.0.0.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
.1.1.1.1.1.1.1 (because it's more than 32 levels deep). I was quite annoyed
because I had to kill my VNC session :-( Of course, with this fix, it just
takes forever to expand 70000+ newsgroups, so perhaps I should just disable
ExpandAll for newsgroups?

Comment 12

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

(In reply to comment #11)
> alt.0.0.0.0.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
> .1.1.1.1.1.1.1 (because it's more than 32 levels deep). I was quite annoyed
> because I had to kill my VNC session :-( Of course, with this fix, it just
> takes forever to expand 70000+ newsgroups, so perhaps I should just disable
> ExpandAll for newsgroups?

Neil, is this issue already present in SeaMonkey?

Comment 13

[[e-mail]]

(In reply to comment #12)
>(In reply to comment #11)
>>alt.0.0.0.0.0.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
>>.1.1.1.1.1.1.1 (because it's more than 32 levels deep). I was quite annoyed
>>because I had to kill my VNC session :-( Of course, with this fix, it just
>>takes forever to expand 70000+ newsgroups, so perhaps I should just disable
>>ExpandAll for newsgroups?
>Neil, is this issue already present in SeaMonkey?
No, it only makes the patch unusable, although I guess you wouldn't be able to
subscribe to that group in tree view in either SeaMonkey or Thunderbird.

Comment 14

[Jan Varga [:janv]]

actually, shouldn't this be an array (w/o a max size/depth)?
enn, what do you think?

Comment 15

[Jay Smith]

Please, no disrespect intended, but I have observed that most developers don't really use IMAP heavily.

I don't know what the difference in techniques being discussed is, however, as a "super user" of Mozilla Mail with IMAP, I have found that the developers have consistently underestimated and not fully understood the degree to which _some_ users/companies use this stuff.  It seems that it was originally written to handle only a few dozen mail boxes on IMAP -- at least it feels that way.

In my case, we are using this for multiple companies, multiple departments, multiple functions.  Thus the folders run about NINE (9) levels deep and any given folder may contain dozens or hundreds of mail boxes.  For example, every customer and vendor of a department has its own mailbox, or if it is big customer or vendor, it potentially a folder containing multiple mailboxes.

My point is that this Collapse All, Expand All feature should be able to really handle _ALL_ not just a quantity that a developer who really does not use IMAP much thinks might be "enough".

Jay