Closed Bug 50131 Opened 24 years ago Closed 23 years ago

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


(SeaMonkey :: UI Design, defect, P3)


(Not tracked)



(Reporter: burnus, Assigned: akkzilla)



(Keywords: helpwanted, platform-parity)


(1 file, 3 obsolete files)

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 
./ ./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 804b0002 
Document 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
nav triage team: nsbeta3-
Whiteboard: [nsbeta3-]
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
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
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.
we're friendlier on windows.
Keywords: mozilla1.0, pp
Target Milestone: Future → ---
*** Bug 73901 has been marked as a duplicate of this bug. ***
*** 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
necko deals with URL's not paths.  We need a scheme to work with.

it is a frontend problem.  
so uriloader?
maybe.  But how will  know that you are talking about file:///home/dougt, and
not http://home/dougt?  
/home/dougt indicates file:, home/dougt indicates http:
that won't work.  "home/dougt/" could be relative to the cwd.  
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.
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.]
-> uriloader
Assignee: dougt → mscott
Target Milestone: --- → Future
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. ***
-> 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
*** Bug 83898 has been marked as a duplicate of this bug. ***
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).
*** Bug 97300 has been marked as a duplicate of this bug. ***
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?
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?
Please create a new bug for that problem.
*** Bug 102210 has been marked as a duplicate of this bug. ***
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.
Timeless tells me that it doesn't work on Windows now either.  All/All.
OS: Linux → All
Hardware: PC → All
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:
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.$ (Of course using a proxy still breaks that, and I'm still in
favor of removing it
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
Target Milestone: Future → mozilla0.9.8
Attached patch Proposed fix (obsolete) — Splinter Review
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.
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.
As timeless said

Please make it

#if defined(XP_WIN) || defined(XP_OS2)
*** Bug 107476 has been marked as a duplicate of this bug. ***
Attached patch Revised patch, XP_WIN || XP_OS2 (obsolete) — Splinter Review
Here's the new patch, using 
#if defined(XP_WIN) || defined(XP_OS2)

Looking for review ..
Attachment #56366 - Attachment is obsolete: true
r=mcafee, yank the printf?
Oh, oops.  Okay, removed the printf, and changed the "many not" comment at the
same time.
Attached patch one more version (obsolete) — Splinter Review
Removed printf, fixed comment, otherwise same.
Attachment #58020 - Attachment is obsolete: true
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
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 on attachment 58408 [details] [diff] [review]
Patch with better error checking

seems quite reasonable to
Attachment #58408 - Flags: superreview+
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.)
Closed: 23 years ago
Resolution: --- → FIXED
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?
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
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
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.
New bug for relative paths?

(try ./etc/hosts in Linux... I bet I know what happens...)
mozilla ./test.html 
works for me Linux 2001112911 (Mandrake 8.1).

mozilla test.html
works, too, surprisingly enough...
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
Keywords: relnote
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.