On Windows mozilla's associations for JPEG files are "Mozilla Joint Photographic Experts Group Image File" This is rediculously long. #1: Mozilla shouldn't even be in the name, because a)if the browser is their default browser they would know that it already opens up with Mozilla b)It isn't Mozilla's format, it is a web standard. #2: Joint Photographic Experts Group should be condensed to JPEG because a) that is what everybody knows it as a JPEG file b) JPEG is to the point "Hey Joe! Can you send me that Joint Photographic Experts Group file you made yesterday." #3: Image File, maybe redundant, however maybe not. So I propose a change to "JPEG Image File", the icon it is given being substantial enough to know what opens it up. Likewise I propose for gifs: "GIF Image File". "Damn, I lost that Mozilla Graphics Interchange Format Image File of my dog."

A couple of days ago someone came onto #mozillazine asking how to get mozilla as he had a Mozilla HTML file. This proved confusing for everyone concerned and de-emphasises the fact that we don't have our own HTML version any more :)

a. Drop Image from both b. I think we already have a bug for this. c. Definitely drop mozilla d. I'm not sure about compressing JPEG and GIF, if i want to know a file's extension i'll look. If I want to know what a file is what should i do? double click it, and then go online and try to find out? in case my suggestion for d doesn't scare you i'll remind you that double clicking exe's, js's, vbs's, .doc's and many others can lead the user to a virus which is _not_ good. [obviously labeling exe, js, vbs, doc and others as 'exe file' 'js file' ... would be useless and _bad_] cc people who might have thoughts about file hinting.

not an installer issue. the installer does not set such associations. over to Vishy

nav triage team: marking nsbeta1+, p3, and mozilla0.9.5

->law/0.9.7, p4, should use JPEG Image, GIF Image, HTML Document (or whatever IE uses), etc. Typical users don't know or care what these acronyms stand for, they just want to be able to categorize the file. Why should we try to impose a completely different system for that than the dominant browser?

Resetting target milestone for all "window integration" bugs to mozilla0.9.8. I'm working on performance and won't get to that till next milestone.

Not knowing much about actual moz code, I'm not 100% about what I'm about to say. This bug really annoys me so I got down to looking and found this in lxr and found http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks.cpp#78 It looks like the fix to this bug is just swapping strings in this file. Having looked at a clean WinXP install, the values should probably be: JPEG Image GIF Image PNG Image XML File Mozilla XUL File HTML Document

I strongly agree with everything noted in the initial submission. I had just notitced my photos were saved as "Mozilla JOint Photographic Experts Group" file types and was completely confused until it clicked that the acronym was J.P.E.G.) Typical users of an embedded browser would be way confused by the long names, not to mention what "Mozilla" means. An example from a consumer email we received: "It changed all my file associations through out my computer To Mozilla Language which I didn't want..." (I added "file type naming" in the summary line)

Not getting to this, either.

added nsbeta1...so it gets looked at later.

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

Bill, what would you say about the proposed idea to just remove "Mozilla" altogether?

I have no problem with that. I'm debating whether we should invent new "file type descriptions" at all; there's another bug on that.

Spam: Moving out bugs that there is no time for. Please note that some of these will hopefully be fixed in the course of fixing bug 59078. I just can't commit to fixing them all.

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

nsbeta1+ per ADT triage team, should shorten and remove branding (e.g., just JPEG, no Mozilla or Netscape)

->1.0

New names for the extensions along the way Windows does them, although .BMP is BMP Image for the sake of consistency. I've also changed the naming of the class keys to the dotted model (like Mozilla.JPEG) commonly used. What do you think about that?

<q class="soapbox qaignore">i'd still like us to not register Bitmap or Icon. We don't register Text file, there's no reason for us to register Bitmap or Icon either, we are not the lightest app out there, certainly not the most useful. Users want to be able to edit bitmaps, we can't do that. Users want quick results. We aren't. </q>

Hmm... I could second that. I can change the patch to ignore bmp and ico, if that's better. Well?

Isn't .jpg more standard than .jpeg (on Windows anyway)?

As an extension, .jpg is more common, but IE calls it JPEG Image (and .jfif is also "JPEG Image")

I think that removing the association of .ico and .bmp should be separated to another bug. In any case it's beyond me, because it will need changes to prefs etc. also.

The patch looks good, but I'd like to discuss these issues: 1. If we change things (e.g., "MozillaJPEG" to "Mozilla.JPEG") then this might throw off the code that tries to detect what the registry contents were previously and our ability to restore them. Resetting "jpeg" would restore the old "MozillaJPEG" instead of going back to what it was previously. We could add code to deal with that, though. 2. Rather than hardcode descriptive names, I'm thinking of just preserving the descriptive names already in the registry. E.g., take the descriptive name of jpegfile and use that for our "MozillaJPEG." Comments on that strategy?

re: .ico and .bmp Maybe the way to handle these is to not handle these by default. We can offer them in prefs so the user can choose to have Mozilla display them if they like.

Hmm.. I've thought that the version responsible for creating the registry entries is also responsible for removing them. Of course it isn't always so simple, so I don't mind keeping the names same (I can create another patch in a minute, if requested). About getting the descriptions from existing entries, a good idea. I could probably create the code to do that also. Only thing thats come to mind are localized versions (but maybe it's actually better to have all the possible entries in the language Windows has) and the case if they decide to rename jpegfile's description to "Micros... JPEG Image" or something similar.

Names of the keys are back to their old values. Descriptions have the new values. When a key is added, the description is taken from existing registry settings if available (such as htmlfile and jpgfile). I've tried to follow the style used in the code. Comments about the changes, please?

Oh, forgot one change: this new patch should also switch off .ico and .bmp handling by default.

re-assigning 'several bugs at once' to morse@netscape.com.

nsbeta1- per ADT triage team. ->ere@atp.fi to tweak patch til its ready.

+ nsCAutoString newDesc; + if ( defaultDescEntry.currentSetting().IsEmpty() ) { + newDesc = desc; + } else { + newDesc = defaultDescEntry.currentSetting(); + } This fetches the setting twice. More efficient would be: + nsCAutoString newDesc( defaultDescEntry.currentSetting() ); + if ( newDesc.IsEmpty() ) { + newDesc = desc; + } Aside from that, it looks excellent.

Changed as suggested by Bill Law.

Comment on attachment 75049 [details] [diff] [review] Optimized patch to change the descriptions and take them from existing keys if available r=law

I hope this will differentiate ".htm" from ".html". I have 2 files on my drive, one of each, and right now can't tell which is which with the current spelled out file type. (I hope this is a case to nsbeta+ this baby.)

IMO, the file type description isn't really meant to tell the extension. If you need to find out the exact extension, you can tell Explorer to show the extensions (on Win2K this is Tools -> Folder Options -> View, untick "Hide file extension for known file types").

renominate for topembed if the patch is available. Nice to have, but not a blocker

Same as 75049 but no taking of the comments from existing keys, if it decided that this is better. Still contains the default association changes for bmp and ico.

Comment on attachment 75049 [details] [diff] [review] Optimized patch to change the descriptions and take them from existing keys if available sr=jag

Renominating for topembed, as the patch has r,sr.

Comment on attachment 75049 [details] [diff] [review] Optimized patch to change the descriptions and take them from existing keys if available a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Fix checked in to trunk.

Oops, I forgot to change the status.

Why is this nsbeta-??? I have just discovered a loss of functionality due to this issue: When I rightclick on JPEGs that are marked as "Mozilla JOint etc." and select "Open" that NOTHING HAPPENS. Expected: "Open" pops out available applications to open JPEGs with. That works with all of my "normal" JPEGs. Jaime can you get it on the branch??

"Open with" WFM using trunk build 6/20 However, for JPEGs served from a database where there is no .jpg extension on the filename, they are still saved the "old" way. Examples: some JPGs are saved as .jpg and some as MOzilla Joint.... Saves as Mozilla Joint PHotographic... with Mozilla logo as icon: http://cdn.netscape.com/wptonrns/20020620_60x60_01_sylvestertweety http://cdn.netscape.com/wpsports/clemens78 Saves as .jpg with generic icon as expected: http://cdn.netscape.com/wpcelebrity/02050790x70hotnot.jpg http://www2.warnerbros.com/main/touts/secondary/tv_friends_joey_fall2001.jpg

Terri, can you verify this fix on the branch, since the code was checked in prior to cutting the branch.

Verified Fixed on win XP branch build 2002062005, all images are saved as jpeg and jpeg is listed under Preferences->system->Windows should use Netscape to open these file types Susie, I do see your problem with these images: http://cdn.netscape.com/wptonrns/20020620_60x60_01_sylvestertweety http://cdn.netscape.com/wpsports/clemens78 But I only see that problem on trunk

I take that back, these URLs still save as Mozilla Joint PHotographic...: http://cdn.netscape.com/wptonrns/20020620_60x60_01_sylvestertweety http://cdn.netscape.com/wpsports/clemens78 using win 2k branch build 2002200608, removing keyword

I think you might have to clean up your registry manually because the registry handling does not overwrite old association names created by old Mozilla versions. Lauch RegEdit and check the contents of HKLM\HKEY_CLASSES_ROOT\MozillaJPEG and others. You can also delete them so that Mozilla will recreate them.

Okay, that does the trick, but how will we clean this out for users that upgrade? Adding keyword back

We could always overwrite the existing registry keys, but there was a comment against this as well as my initial plan to change the key names. One possibility would be to check for the old ones somewhere (in the installer?) and delete them if necessary.

adding xpinstall folks to see if they have insight on how we could cleanup the registry. however, this sounds like another bug. for now, i think this bug should remain as verified1.0.1, as teri has indicated.