can't open local file with semicolon in path; attempts to open path prefix before semicolon instead

RESOLVED WORKSFORME

Status

()

Firefox
File Handling
--
minor
RESOLVED WORKSFORME
8 years ago
2 years ago

People

(Reporter: Dave Webber, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

If I attempt to open a local file in Firefox with at least one semicolon in its path (be it the name of the file, or a directory or volume containing it at any level up) by double-clicking it, by right-clicking it and selecting Open With -> Firefox, by drag-dropping it onto Firefox's icon in the Dock or in Finder, clicking it on the dock, or by sending an Apple Event (as by running an AppleScript), Firefox will attempt to open the part of the path preceding the first (and possibly only) semicolon therein, whether there is a file system object at this path or not, and regardless of what type of object it might be. [So: If there is nothing at this path, Firefox will show a "File not found" error page. If there is a an object at this path, Firefox will open it if it is a file or list it if it is a directory (even a volume). If the semicolon is the first character of the name, Firefox will list its parent directory.] Additionally, if I send an Apple Event to open a path containing a semicolon for which no object exists, Firefox will exhibit the same behaviour, opening or listing (as appropriate) an object at the path preceding the semicolon if one exists, or showing the "File not found" error page. In any case, the location bar will reflect the truncated path which Firefox attempted to open.

If, on the other hand, I open the item by selecting Firefox's File -> Open menu item [or command+O], by directly navigating to the file through the location bar, by navigating to its parent directory and opening it from the directory listing, by drag-and-dropping onto a Firefox browser window's location bar, tab bar, or content area, or by using the "open" command-line utility, Firefox's behaviour is correct in this regard.

Reproducible: Always

Steps to Reproduce:
[Presuming Firefox is your default browser:]
1. Open a file named "foo;bar.html" through Finder or the Dock.
1. Open a file named "baz.html" in a directory named "foo;bar" through the same.
1. Oprn a file named ";qux.html" through the same.
Actual Results:  
In the first two cases, if there is no item "foo" in the same directory as the file "foo;bar.html" or the directory "foo;bar", then you'll see a "File not found" error page. If there is a "foo" there, Firefox will open "foo". In both these cases, the path in the location bar will end in "foo".

In the third case, Firefox will list the directory in which ";qux.html" is.

Expected Results:  
Firefox should open "foo;bar.html", "foo;bar/baz.html", or ";qux.html".
(Reporter)

Updated

8 years ago
Severity: minor → normal
(Reporter)

Updated

8 years ago
Severity: normal → minor
(Reporter)

Updated

8 years ago
Severity: minor → normal
(Reporter)

Updated

8 years ago
Severity: normal → minor

Comment 1

8 years ago
Recent comments for Bug 530064 seem to be referring to this.  As discussed there a '?' character in the file name also causes this.
(Reporter)

Comment 2

8 years ago
I was beginning to suspect I might've done something incorrectly when I submitted this bug. I did waffle on the importance several times, before I had CC'd other  bugs and came to realize that everyone on the CC list got bugmail on all those changes (sorry about that). So, does the fix for 530064 also apply to this?
(Reporter)

Comment 3

7 years ago
Sorry, I forgot to check into this. It is fixed, presumably by the fix for bug 530064. If the summary for that bug were to be updated to include semicolons and question marks (the latter of which were brought up in the comments there), then I suppose this bug would be a duplicate of that one.
Closing this bug according to reporter's latest comment
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.