502487 - relative paths to local files with '#' characters not handled properly

Status: UNCONFIRMED

(Firefox :: File Handling, defect)

Description

[Mark Tiefenbruck]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Pidgin stores its log files in html format, so I like to use firefox to browse them. For example, using bash from my home directory, I might run this:

firefox .purple/logs/irc/markt\@irc.mozilla.org/#firefox.chat/2009-07-05.122935-0700PDT.html

However, this results in a new tab browsing the .purple/logs/irc/markt\@irc.mozilla.org/ directory. If I include a ~/ before the file path, on the other hand, the log file is opened as expected. My assumption is that the problem is with the '#' character, since opening other relative paths works fine.

Reproducible: Always

Comment 1

[Nochum Sossonko [:Natch]]

Why are you using back-slashes in conjunction with forward-slashes? At least on Windows I'm finding that it confuses Firefox.

Comment 2

[Mark Tiefenbruck]

Because this is Linux. Forward slashes denote directories. Backslashes are used to disambiguate special characters used by the shell. Neither firefox nor the shell script that launches it will ever see that backslash. It was put there by bash when I tab-completed the directory name.

Comment 3

[Matthias Versen [:Matti]]

I think you have to escape the "#" char because it's a special char in any URL like "/" or "\" or a space.

Comment 4

[Mark Tiefenbruck]

That was one of my concerns as well; however, as noted in my initial report, the file loads fine when a full path is used, with no escaping required.

Comment 5

[Mark Tiefenbruck]

At any rate, it's clear that relative and absolute paths are being interpreted differently. I would imagine that command line arguments would be handled as follows (assuming it's not a defined option like --help):

1. If a protocol is given, e.g. 'http:', pass the argument off to the given handler.

2. Check local filesystem for matching files. On *nix:

  a. If the argument begins with '~/', substitute the user's home directory. If the argument begins with '~blah', substitute user blah's home directory. If the argument does not begin with '/', prepend the current working directory and a '/'.

  b. Pass off to file location subroutines. These would check to see if the entire path is a file in the filesystem. If not, back off to '?' and '#' characters from the end backward.

3. If no matching files, assume http. Pass off to the http protocol handler, ideally the same subroutine used by the URL bar so that keyword commands and plugin functionality can be used.



This bug reveals that step 2 does not happen as I would expect. My own testing shows that step 3 does not happen quite as described. If I pass something with a space in it, firefox attempts to open it as a local file and presents an error page if the file doesn't exist. However, alphanumeric arguments seem to go through both steps 2 and 3.

I realize there may be problems with the described handling process. I'd appreciate seeing intentional reasons the actual behavior differs.

Comment 6

[Nochum Sossonko [:Natch]]

This would be a core bug.

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> firefox .purple/logs/irc/markt\@irc.mozilla.org/#firefox.chat/2009-07-05.122935-0700PDT.html

To Mark Tiefenbruck(bug opener):

AFAIK, positional parameter(with no swich) is <url> (same as data of -url switch).
> http://kb.mozillazine.org/Command_line_arguments
> https://developer.mozilla.org/En/Command_Line_Options
> (possibly "no protocol" == "file:// URL")
Can we see document which says "positional parameter is local file path"?

AFAIR, (a) sniffing like yours + translation to file: url, or (b) new -file switch, were discussed in other bug for user's convenience. (Sorry but I couldn't reach the bug again yet.)
In that bug, simple (a) was tried but it was not successful because sniffing is sniffing. It's impossible to distinguish already-escaped-string and not-escaped-yet-string. (imagine %20 case. it's space? Or "%20"?). It's reason why new -file switch will be required to support local file with non-escaped string in addition to -url switch with escaped string.

Comment 8

[WADA:World Anti-bad-Duping Agency]

FYI.
Similar bug(already fixed) is found for Thunderbird(.eml file if Thunderbird).
> Bug 376089 open .eml files from the command line using relative path fails
Internal conversion to file: url or interpretation as local file path seems to be already available and have worked well with absolute path only.

Comment 9

[WADA:World Anti-bad-Duping Agency]

Oh, you said as next.
> If I include a ~/ before the file path, on the other hand, the log file is opened as expected.
> since opening other relative paths works fine.
> the file loads fine when a full path is used, with no escaping required.

It looks that .purple/logs/.../[e-mail]/#firefox... is treated as file: url without "file:/" instead of local file path.
Does relative path with escaped '#' work? 
> firefox .purple/logs/.../[e-mail]/%23firefox...
What is displayed in URLbar or error message?

Comment 10

[Mark Tiefenbruck]

Sorry for the delay; I've been out in the mountains for a few weeks. Converting the # to a %23 works, but that's annoying, as tab-completion won't work then. I'd have to tab-complete the filename, then go back and change it. Using the -file argument works (I didn't know about it, since there's no man page for firefox and firefox -h doesn't say anything about it; where is one supposed to find firefox's command line arguments?), but it opens the page in a new window instead of a new tab.

Nothing is perfect, but you can make educated guesses about whether something needs to be escaped. The default should be to maximize the probability of guessing correctly. If I have a file or directory beginning with '#', what are the odds that I meant to refer to an anchor tag in firefox's directory listing rather than that file?

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> Converting the # to a %23 works, (snip)

".purple/logs/.../[e-mail]/#firefox..." is treated as file: url without "file://", instead of local file path. 

Because you say next, it sounds "." only problem.
> If the argument begins with '~/', substitute the user's home directory.
> If the argument begins with '~blah', substitute user blah's home directory.
> If the argument does not begin with '/', prepend the current working directory and a '/'.
Does ".purple/" mean hidden directory under current working directory at terminal etc.?

Does "starting period" have special meaning in file url without file:// or url without http:// for Fx?
Or simply lack of care for "starting period" of local file path?
Or hidden directory is excluded from local directory search then jumps to file: url process?

> If I have a file or directory beginning with '#', what are the odds that I meant to refer to an anchor tag in firefox's directory listing rather than that file?

Experiment will answer your question :-)
My guess: one of next.
(a) file://<current_working_directory>/#... => firefox's directory listing
(b) local path of <current_working_directory>/#... => #... in firefox's directory
How about ".purple/A%20B/#XYZ"? I guess "A B" is searched, then "not found".  
 
> Using the -file argument works

Oh, it's good news. Enhancement was probably done for user's convenience.
If it's standard feature which will be kept by future releases, this bug may be closed as WONTFIX by someone...

> I didn't know about it, since there's no man page for firefox and firefox -h doesn't say anything about it;

Please open separate bug for it.

> but it opens the page in a new window instead of a new tab.

Please open separate bug for it.

Comment 12

[WADA:World Anti-bad-Duping Agency]

FYI. Bug 267980 is found for issue on non-ascii file name.