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

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Tom Kaczmarski]

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.

Comment 1

[Tom Kaczmarski]

Attachment: screen shot of HTML action showing the mangled path registered with Windows

Comment 2

[Daniel Veditz [:dveditz]]

It's the browser that sets up those items --> law

Comment 3

[Henrik Gemal]

really reassign...

Comment 4

[timeless]

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?

Comment 5

[Tom Kaczmarski]

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

Comment 6

[Henrik Gemal]

We shouldn't be using 8.3 names anywhere...

Comment 7

[Alexey Chernyak]

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.

Comment 8

[Alexey Chernyak]

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

[Karsten Düsterloh]

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

Comment 10

[redxii1234]

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..

Comment 11

[Andrei Purice]

Marking this as Resolved > Incomplete since the last real activity on this issue was 16 years ago (reported for Windows 2000) and it might not be relevant anymore.
Feel free to re-open it if it's not the case and the issue is still relevant.