'Show items that contain' disabled in subscribe dialog

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: version 1.0 (20041206)

For some reason, the subscribe option, when invoked in an imap server
has the "Show items that contain __________________" greyed out.

If there is some reason this dialog box cannot be made functional, perhaps it
shouldn't be displayed at all as it is confusing and adds to visual clutter.

Otherwise, why is it greyed out and can that be fixed?

Thanks,
-linda

Reproducible: Always

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/

still reproducible in "version 1.0.6 (20050716)"
am unable to type any text into the "show items" dialogue.

It is still greyed out and non functional. Maybe it is
supposed to be a joke to put a non-functional
search dialog at the top of page displaying an
IMAP folder list?

Does it ever work? I only use IMAP so I've
never seen the dialogue work.

it's there for news. Personally, I'd hide it for imap, but UI folks seem to
prefer disabling UI items instead of hiding them. Is this a case where you'd
prefer it disabled instead of hidden, Neil? Short of making it work for IMAP, of
course :-)

Maybe if we renamed it "Show newsgroups containing:" it would make more sense.
As for making it work with IMAP, there's no obvious way of displaying the
results (unlike newsgroups which are known to use a "." separator).

Ancient thought in UI world was that if there were options that didn't
apply or that the user would not be able to use, you simply didn't confuse
them by presenting them -- it causes them to wonder how to enable them
or wonder why they don't work or when they will be working.

If it's a feature that is planned for near future support, then I wouldn't
waste time hiding the dialogue. On the other hand, if it isn't a feature
that is planned soon -- I'd like to note that this feature has been available
in MS Outhouse since at least the 2000 version, so maybe this should be
an RFE.

But as long as it remains an inactive or unplanned RFE, I'd call it a
UI bug that it is displayed for IMAP folders at all -- minor. But it
is a probably a 'normal priority feature deficit' (um, is that a bug
or a RFE; hard to classify it w/o some predefined "spec" or feature
set to which T-bird/Moz should measured.

*However*, given that it works for other users (assuming on local
folders and maybe POP? or is it even applicable to POP...it doesn't have
folders, does it? Been a while since I POPped (*ahem*)), then it seems to
be the intention to provide search functionality for folder names.

If "Ability to search for folder names" is the "stated feature" that one
wishes to support, then this is still a bug.

If one creates a odd feature list, along the lines, of "if [it is a day
ending in 'y' and if it is a month containing the letters 'u' or 'r' and if]
it is a local folder store, or news account (others), then support searching,
else not. [i.e. this really is only not supported for folders of IMAP type]

Ok, I bracketed some excessive specificaly malarky to highlight the point.
Ideally, (in my mind) features should be implemented orthogonally to data
types on which they would make sense -- which in this case would include
feature-search(data-type-folder), where IMAP does fall into the valid
classs of folder data types.

But hey, just my "backseat driver", leachy-user point of view (with
some "minor" <10 (in base 32, but not hex) number of years of design
experience; sorry, bad habit of being a bit of a "smart" (dumb?) ass.
Please don't take it personally, I'm just generally irreverent which
has the bad and unintended side effect of "endearing" (*cough*) people
towards me and my ideas. Can you tell I have the social skills of a
2nd generation CompSci type? (*picture: me kicking myself for talking
too much*)

(In reply to comment #4)
> As for making it work with IMAP, there's no obvious way of displaying the
> results (unlike newsgroups which are known to use a "." separator).

Neil, can you elaborate on how not having a known separator is a problem?

(In reply to comment #6)
>Neil, can you elaborate on how not having a known separator is a problem?
How would you differentiate between multiple identically named folders?

*** Bug 453159 has been marked as a duplicate of this bug. ***

agree, this should be removed or reworded. Totally not obvious why it was greyed out.

Still no change (TB 45.7.1). I would really love this IMAP folder filter as a feature, as I regularly look for certain folders in a long list to subscribe/unsubscribe. I'd expect it as a filter to the IMAP folders list, so there might evolve no problem from multiple identically named folders (as long as you consider their full path).

From the looks of it, still no change as of TB 60.3.0. We have an extensive folder list and since every subfolder is expanded in the view, it takes a long time to find the folder I want to subscribe to or unsubscribe from.

*** Bug 1856184 has been marked as a duplicate of this bug. ***