In the open dialog in Mozilla, both in the browser, mail/news, etc, the File Type description of All Files should "All Files (*.*)" in stead of just "All Files" Places to changes: http://lxr.mozilla.org/seamonkey/search?string=%22All+Files%22

[reducing severity to Enhancement Request.] ...of course, such a change should only be made if it can be done without affecting the Mac builds, as Mac users don't use foobar.baz styled file names.

agreed. reset the bug to "won't fix".

Err...rather, gemal's suggestion is how other Windows applications work --- so we should be doing it the same way, right? We just need to be sure that it's only changed on the Windows platform. Re-opening, and assigning to Don.

Reassigned to Don.

Also remember that in the File Upload dialog it's: "all files" and not "All Files"

This isn't an RFE. We're just not following the UI guidelines. :-)

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.

Move to M20 target milestone.

Oops. Should be M21.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: Nice to have, but won't hold beta1 for it, marking nsbeta1-

Marking nsbeta1- bugs as future to get off the radar.

found it at: http://lxr.mozilla.org/seamonkey/source/xpfe/components/filepicker/res/locale/en -US/filepicker.properties normal window programs include the filespec (ala *.html) in the title.

-> law?

Actually, this change should effect all the file filters. For example, on the open file dialog, the filter for HTML files should actually say something more like "HTML Files (*.html, *.htm)" obviously reflecting the actual filter. This is just a good habit and prevents confusion, especially in environments where the extension is still present but hidden from the user anyway. I personally think because of this this bug deserves a bit more attention than it's got right now.

In addition to comment #13, I beleive the other part of this is at http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsFilePicker.cpp#746

This patch adds the extensions to the filter titles in the dropdown of Open File. note: I have not been able to test this on a mac, someone plz. verify that.

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters timeless: I added you since you reviewed the last version.

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters get an xpfe owner to sign off

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters Instead of duplicating this text, could you change the xxxTitle to be "xxx Files (%S)" and then from the js substitute the xxxFilter? E.g. bundle.getFormattedString("xxxTitle", [ bundle.getString("xxxFilter") ]); That'll save you on duplication and maintenance (see xulTitle in your patch as a good example of why).

Thanx for the commment, I'll try and do it this weekend.

If no one is still working on this, I'd be glad to take this over... however, jag, if you're reading, I have a question about your suggestions in your last comments. Thanks.

Note that the linux filepicker already combines the filter into the label.

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters jag's comments don't make sense. we have: text(Filter|Title), Text Files, *.txt; *.text.

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters oh blah. it makes sense, it's just a bad idea. actually, all of this code is bad. for one there's a perf penalty. for another, it forces behaviors which will annoy translators and others. what bothers me the most is that the api doesn't offer mime types. on beos i want: HTML Files (text/html) [but really, the text/html doesn't need to be listed in the file type list, it's just what would be listed] not HTML Files (*.htm; *.html). Note that BBEdit (Lite) has: Enable [All Available |v] Any File - Text Files PICT Files QuickTime Movies QuickTime Images So this probably really should be a toolkit decission and not a localizer one.

> for one there's a perf penalty. Yeah, sure. A significant perf penalty though? I doubt it. Worth not having to duplicate the filter? I think so. > for another, it forces behaviors which will annoy translators and others. How so? By using formatString they can place the "filter" wherever they want it in the title, or even leave it out. The MIME type thing is a separate bug. Neil: thanks for pointing out that linux already does this. http://lxr.mozilla.org/mozilla/source/xpfe/components/filepicker/res/content/filepicker.js#116 This code is currently hardcoding the "( *.html; ... )" part which is l10n unfriendly. Once we have the generic solution this code should be updated to use that. It looks like we'd only have to put the formatString code in both the |appendFilters| (plural) implementations, right?

Comment on attachment 128102 [details] [diff] [review] Adds extenstions to the titles of the filters This is Mac-unfriendly.

i'm trying to get help. but no administrator is here. my brand new home machine has the same exact stuff and i've had it for years. i've reported to police umteen times and the fbi. alot of trouble but no help. thx jbt23@nau.edu thank you all for your efforts, i know that since this is not my machine but at the university i can't get too much help. any ideas? pls let me know at jbt23@nau.edu