Enable mozilla to accept absolute path to local files at launch w/o file:/// prefix

VERIFIED FIXED in mozilla0.9.8


UI Design
18 years ago
13 years ago


(Reporter: Tobias Burnus, Assigned: Akkana Peck)


({helpwanted, pp})

helpwanted, pp

Firefox Tracking Flags

(Not tracked)



(1 attachment, 3 obsolete attachments)



18 years ago
Hi (2000-08-23-21)

mozilla /home/foo/index.html

doesn't load file:///home/foo/index.html (this works with NS 4.x)

cd $HOME; mozilla bar/index.html

doesn't load file:///$HOME/bar/index.html, but tries to resolve `bar' which
obviously does not exist as domain.
yeah, i also tried this,

  ./netscape /u/sairuh/Tests/sairuh_beta1.html

and all i got was the default webpage. blah, i think this worked in 4.x, but
will doublecheck... console output (btw, vrfy is the name of the profile i
selected to launch, from the profile manager gui):

sairuh@hopey 76: ./netscape /u/sairuh/Tests/sairuh_beta1.html 
./run-mozilla.sh ./mozilla-bin /u/sairuh/Tests/sairuh_beta1.html
Move window by 639.5,511.5
start with profile: vrfy
ProfileManager : StartApprunner
profileName passed in: vrfyWEBSHELL- = 0
 I am inside the initialize
 Hey : You are in QFA Startup 
(QFA)Talkback loaded Ok.
CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///u/sairuh/.mozilla/vrfy/chrome/user.css' failed.  Error code: 16389
creating new nsJSAimChatRendezvous
Setting content window
*** Pulling out the charset
in SetSecurityButton
Error loading URL http://home.netscape.com/: 804b0002 
Document http://home.netscape.com/index1.html?cp=hom08pr2 loaded successfully
Keywords: nsbeta3
yeah, in 4.7x local files will load without the file:/// prefix. adding 4xp kw.
(at least they do load in mozilla/nscp6 when i specify file:///. whew.)
Keywords: 4xp

Comment 3

18 years ago
nav triage team: nsbeta3-
Whiteboard: [nsbeta3-]


18 years ago
Keywords: helpwanted
*** Bug 59730 has been marked as a duplicate of this bug. ***
Keywords: nsbeta3
Whiteboard: [nsbeta3-]
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
Assignee: don → vishy
Netscape Nav triage team: this is not a Netscape beta stopper.
Keywords: nsbeta1-, relnote

Comment 7

17 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future

Comment 8

17 years ago
I feel this should be addressed for mozilla0.9 or for sure by mozilla1.0 since 
old versions of Netscape handled files this way, and many linux/unix 
icons/calls in programs will have to be changed due to this.

Comment 9

17 years ago
we're friendlier on windows.
Keywords: mozilla1.0, pp
Target Milestone: Future → ---
*** Bug 73901 has been marked as a duplicate of this bug. ***

Comment 11

17 years ago
*** Bug 84913 has been marked as a duplicate of this bug. ***
in bug 84913, not specifying file:// for the url in the Home page Location
textfield of the Navigator prefs panel also results in the file not loading.

dougt, should this then be considered a networking: file bug, or [still] and xp
apps bug? i'm tentatively thinking the former...but do let me know who the best
owner would be. thx!
Assignee: vishy → dougt
Component: XP Apps: Cmd-line Features → Networking: File
QA Contact: sairuh → tever

Comment 13

17 years ago
necko deals with URL's not paths.  We need a scheme to work with.

it is a frontend problem.  

Comment 14

17 years ago
so uriloader?

Comment 15

17 years ago
maybe.  But how will  know that you are talking about file:///home/dougt, and
not http://home/dougt?  

Comment 16

17 years ago
/home/dougt indicates file:, home/dougt indicates http:

Comment 17

17 years ago
that won't work.  "home/dougt/" could be relative to the cwd.  

Comment 18

17 years ago
I don't think defining the lack of / as indicating http: is a great loss.
"Relative to cwd" isn't very useful in a browser (and you could still hack
around it by allowing "./foo" notation for relative file paths). Also, this way
is consistent with other browsers.

Comment 19

17 years ago
chris, uriloader is the right place for this bug.  

dougt/neeti/timeless, feel free to move this over to the more appropriate
component and/or owner, if needed. thx! [i'm unclear as to where uriloader belongs.]

Comment 21

17 years ago
-> uriloader
Assignee: dougt → mscott
Target Milestone: --- → Future


17 years ago
Summary: local files only load with file:/// prefix → local files only load with file:/// prefix on launch
*** Bug 88642 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
-> xpapps + qa contact (hope this is the right place...)

I don't think it's obvious to anyone that a file URL should be given at a
command line. You probably need to wrap the path into a file URL, and document
the expected behavior.
Component: Networking: File → XP Apps: Cmd-line Features
QA Contact: tever → sairuh
this is not limited to the command-line [see bug 84913].
Component: XP Apps: Cmd-line Features → XP Apps

Comment 25

17 years ago
*** Bug 83898 has been marked as a duplicate of this bug. ***

Comment 26

17 years ago
I'm going to separate the "home page prefs" bug because I think that is a
separate design issue. When you are at a UNIX or Windows prompt launching,
having a path makes sense. I am less sympathetic for the home page setting (I'll
explain in that bug).

Comment 27

17 years ago
*** Bug 97300 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
On my windows2000 system double clicking a html-file launches Mozilla, but it is
not showing the file but only my default home file. 
Clicking a file an launching the corresponding program is one of the essentials
in working with windows (and with Mac's etc.). Why is there no milestone (it
only says future) for this, imo serious, bug?

Comment 29

16 years ago
True! Using 0.9.4, build 2001091303.
As a result, other programms can't launch Mozilla with a specific page, which is
very bad (e.g. online help etc.).
Please could someone fix this?

Comment 30

16 years ago
Please create a new bug for that problem.

Comment 31

16 years ago
*** Bug 102210 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
This complicates launching the editor, too: it's a very normal thing to want to
run the editor with a filename argument (or drag a file over the editor icon, or
substitute your favorite comparable UI action).

Is this really only Linux?  Isn't our argument parsing all XP code?  Is it
something like "if it has backslashes in it then we recognize it as a file,
otherwise we don't"?  What happens on Mac (e.g. on OSX, or on OS9 if you drag a
file icon over the browser or editor icon)?  I might be willing to take a crack
at this (it's a real hassle when testing the editor, and I think it should be
done sooner than future, especially if it's a platform parity issue), but it
would be a lot easier if I had some idea what was already known.

Comment 33

16 years ago
Timeless tells me that it doesn't work on Windows now either.  All/All.
OS: Linux → All
Hardware: PC → All

Comment 34

16 years ago
If you got the time, I'll find the time.

Each OS has it's own problems so we should make a list of OS's and entry points
and look at each one. I think you might want to do UNIX first (simplicity) or
Windows (more happy people).

Here's an incomplete list of entry points:


Comment 35

16 years ago
Can't we use the same codepath as entering a URL on the URL bar? That would
simplify things and buy all the extras like (I can't believe I'm saying this) $x
-> www.$x.com. (Of course using a proxy still breaks that, and I'm still in
favor of removing it

Comment 36

16 years ago
Grabbing the bug: I have a preliminary fix for this.  It's XP, except for one
thing: the current argument parsing code accepts '/' as an argument prefix in
addition to '-', except that apparently it only takes / in certain cases.  But
this, of course, will completely break Unix' ability to specify files on the
command line since pathnames start with /.  So I've added #ifdef WIN_32 around
those parts so that only windows will accept / as a flag specifier.  I don't
like platform ifdefs, but this code was already structured using them, except
that the previous ones are XP_PC, not XP_WIN32.  My understanding was that XP_PC
is usually the wrong thing.  Question, does OS_2 want / to be a pathname
specifier or a flag specifier?

Anyway, I use the existing nsIURI/nsLocalFile mechanism to test whether the
argument is already a URI and if not, try to make a local file URL out of it. 
It does not work with relative pathnames, only absolute ones, because
nsILocalFile isn't smart enough to handle local file paths.  Perhaps it should
be, but IMO that smartness should live in nsILocalFile, not here.

In case anyone was worried, I didn't have to add any REQUIRES dependencies to
xpfe; it already depended on netlib so that wasn't a problem.

Reviews and testing (especially on non-Unix platforms) solicited.
Assignee: mscott → akkana


16 years ago
Target Milestone: Future → mozilla0.9.8

Comment 37

16 years ago
Created attachment 56366 [details] [diff] [review]
Proposed fix

Comment 38

16 years ago
Looks good to me. I'd almost suggest removing '/' entirely, as an option
character. The two cross platform UNIX/W32 apps I know of that use command line
options only accept '-' on Windows too. But it's not a big deal.

May (no pun intended) as well fix the typo right there in the comment:
"May or many not" ~= s/n//

While we're here, if it's possible to add the command line's URL into the URL
bar history quick, safe, and easy, it might be nice.

Comment 39

16 years ago
windows should be XP_WIN (esp for NT 64bit, but also w16).

I think OS/2 wants to be like windows.

thanks for not nuking / from windows.

Comment 40

16 years ago
As timeless said

Please make it

#if defined(XP_WIN) || defined(XP_OS2)

Comment 41

16 years ago
*** Bug 107476 has been marked as a duplicate of this bug. ***

Comment 42

16 years ago
Created attachment 58020 [details] [diff] [review]
Revised patch, XP_WIN || XP_OS2

Here's the new patch, using 
#if defined(XP_WIN) || defined(XP_OS2)

Looking for review ..
Attachment #56366 - Attachment is obsolete: true

Comment 43

16 years ago
r=mcafee, yank the printf?

Comment 44

16 years ago
Oh, oops.  Okay, removed the printf, and changed the "many not" comment at the
same time.

Comment 45

16 years ago
Created attachment 58178 [details] [diff] [review]
one more version

Removed printf, fixed comment, otherwise same.
Attachment #58020 - Attachment is obsolete: true

Comment 46

16 years ago
Created attachment 58408 [details] [diff] [review]
Patch with better error checking

Kin asked for better error checking, to make sure that none of the local file
methods return null when we're not expecting that.  Good idea! -- see new
Attachment #58178 - Attachment is obsolete: true

Comment 47

16 years ago
Looks like Radha's name is on the old code.  Radha, can you review the latest
patch, and/or point me to the module owner/super reviewer responsible for this
area?  Thanks!

Comment 48

16 years ago
Comment on attachment 58408 [details] [diff] [review]
Patch with better error checking

seems quite reasonable to me...sr=alecf
Attachment #58408 - Flags: superreview+

Comment 49

16 years ago
Fixed -- full pathname arguments should work now.  (Relative paths still won't
work since there's no way to map them to file: urls, so we don't even try.)
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 50

16 years ago
Netscape 4.7 manages to load x.html in my home when I do "netscape x.html". URL
bar also displays "file:/home/jmd/x.html" (yes, only one ':'). Lynx, w3c, and
links all can do this as well. Should a seperate bug be filed?

Comment 51

16 years ago
Yes, please file a separate bug.  Assign it to me if you like (I doubt anyone
else cares, and I do; cc me if you don't assign it to me outright).  
curious if this just horked the local folders in 3 pane window and the mail/news
account settings?  see also bug 110371 comment #21

Comment 53

16 years ago
This shouldn't have anything to do with mail folders at all (unless you put
folder names on the command line), but feel free to cc me if a bug is filed on
the mail folders problem, and I'll keep on top of it just in case.
ok, here is probably what seems to fix the folders in bug 111018 comment #5

Comment 55

16 years ago
re: "file:/only/one/slash.html", I noticed in this in Nav 4. We map ":/" to
":///" (which would become a valid URL). I don't know if this is good, but we do it.
vrfy'ing fixed with 2001.11.28.0x-comm bits on linux rh7.2 and winnt. not sure
how to verify on Mac...

anyhow, the following tests worked:

./netscape /home/foo/file.html
*or* entering /home/foo/file.html in the urlbar

./netscp6 d:\tests\file.html
*or* entering d:\tests\file.html in the urlbar

once the page is loaded, the url in the urlbar ends up displaying as
"file:///<whatever url previously entered at the cmd-line or urlbar>". also, as
akkana mentioned, relative paths [eg, ./netscape file.html] don't work.

Comment 57

16 years ago
New bug for relative paths?

(try ./etc/hosts in Linux... I bet I know what happens...)

Comment 58

16 years ago
mozilla ./test.html 
works for me Linux 2001112911 (Mandrake 8.1).

mozilla test.html
works, too, surprisingly enough...


14 years ago
Summary: local files only load with file:/// prefix on launch → Enable mozilla to accept absolute path to local files at launch w/o file:/// prefix


14 years ago
Keywords: relnote
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.