Mozilla installation registers the shortened mangled paths with Windows causing the Windows/Mozilla integration to fail to open files associated with Mozilla, e.g. HTML files. Here is an example of the contents of the open action for HTML files under Windows: C:\PROGRA~1\MOZILLA.ORG\MOZILLA\MOZILLA.EXE -url "%1" When an external program such as a chat client tries to launch a URL it fails. However, when I change the path to a non-mangled one: "C:\PROGRAM FILES\MOZILLA.ORG\MOZILLA\MOZILLA.EXE" -url "%1" (aside: the path here needs to be quoted since it contains a space; promiscuous quoting doesn't hurt anything anyway) the chat client has no problems launching the URL. It would be nice if the Installer/Mozilla would register non-mangled paths with Windows to alleviate such problems. It's a real pain to go through all the associations and correct the paths by hand. This is a Windows specific issue AFAIK.
Created attachment 75119 [details] screen shot of HTML action showing the mangled path registered with Windows
It's the browser that sets up those items --> law
Assignee: dveditz → law
Status: UNCONFIRMED → NEW
Component: Installer → XP Apps
Ever confirmed: true
Assignee: law → sgehani
QA Contact: bugzilla → paw
note that we should *not* change the case of the string, nor should we get the short name (which is the complaint by the reporter). reporter: if you try to run C:\PROGRA~1\MOZILLA.ORG\MOZILLA\MOZILLA.EXE does it work?
Assignee: sgehani → law
Component: XP Apps → File Handling
QA Contact: paw → sairuh
If I run Mozilla by hand using the path it works. However, some applications launching Mozilla through a system call fail.
We shouldn't be using 8.3 names anywhere...
Same applies to Firebird and Thunderbird: C:\PROGRA~1\MOZILL~1\MOZILL~1.EXE C:\PROGRA~1\THUNDE~1\THUNDE~1.EXE These are the offending functions: http://lxr.mozilla.org/mozilla/source/xpfe/components/winhooks/nsWindowsHooksUtil.cpp#60 http://lxr.mozilla.org/mozilla/source/mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp#64 Which are used in the following places to set the registry values: http://lxr.mozilla.org/mozilla/ident?i=thisApplication There seems to be a bit of duplication among this code. Note, the registry values that set the icons for File Types and URL Protocol Handlers seem not to require the LFN path to be quoted.
Summary: Mozilla registers mangled (DOS) paths in Windows File Types (mime types) → Mozilla registers 8.3 DOS paths instead of LFN in Windows File Types (mime types)
This code is also marginally relevant. It sets the icon, which as I mentioned above doesn't use quoting for LFN: http://lxr.mozilla.org/mozilla/source/xpfe/components/winhooks/nsWindowsHooksUtil.cpp#760 The only other code in Mozilla which seems to use 8.3 filenames is here: http://lxr.mozilla.org/mozilla/source/xpfe/bootstrap/nsNativeAppSupportWin.cpp#2653 But it is irrelevant to this particular bug.
*** Bug 322299 has been marked as a duplicate of this bug. ***
Even if the paths are fixed manually, it would be as if you had unregistered TB or FF as the default app. It's no longer recognized, so it'll ask you if you want to make it default. If you click Yes, the paths get mangled again. As of Thunderbird 1.5 and Firefox 126.96.36.199, this issue still exists..
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.