Mozilla registers 8.3 DOS paths instead of LFN in Windows File Types (mime types)

NEW
Unassigned

Status

()

Firefox
File Handling
--
major
16 years ago
2 years ago

People

(Reporter: Tom Kaczmarski, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
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

Comment 3

16 years ago
really reassign...
Assignee: law → sgehani
QA Contact: bugzilla → paw

Comment 4

16 years ago
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
(Reporter)

Comment 5

16 years ago
If I run Mozilla by hand using the path it works.
However, some applications launching Mozilla through a system call fail.

Comment 6

16 years ago
We shouldn't be using 8.3 names anywhere...
QA Contact: sairuh → petersen

Comment 7

15 years ago
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)

Comment 8

15 years ago
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.

Comment 9

12 years ago
*** Bug 322299 has been marked as a duplicate of this bug. ***

Comment 10

12 years ago
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 1.5.0.1, this issue still exists..
Assignee: law → nobody
QA Contact: chrispetersen → file-handling

Updated

2 years ago
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.