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 MOZILLA_FIVE_HOME=/u/sairuh/seamonkey/00082508/package LD_LIBRARY_PATH=/u/sairuh/seamonkey/00082508/package/Cool:/u/sairuh/seamonkey/00082508/package:/u/sairuh/linux/seamonkey/package LIBPATH=/u/sairuh/seamonkey/00082508/package:/u/sairuh/seamonkey/00082508/package/Cool SHLIB_PATH=/u/sairuh/seamonkey/00082508/package:/u/sairuh/seamonkey/00082508/package/Cool XPCS_HOME=/u/sairuh/seamonkey/00082508/package/Cool MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= WEBSHELL+ = 1 Move window by 639.5,511.5 start with profile: vrfy ProfileManager : StartApprunner profileName passed in: vrfyWEBSHELL- = 0 WEBSHELL+ = 1 I am inside the initialize Hey : You are in QFA Startup (QFA)Talkback loaded Ok. WEBSHELL+ = 2 CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///u/sairuh/.mozilla/vrfy/chrome/user.css' failed. Error code: 16389 creating new nsJSAimChatRendezvous WEBSHELL+ = 3 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

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

nav triage team: nsbeta3-

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

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Netscape Nav triage team: this is not a Netscape beta stopper.

Marking nsbeta1- bugs as future to get off the radar

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.

*** 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!

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

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

this is not limited to the command-line [see bug 84913].

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

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: http://www.packetgram.com/pktg/mozilla/testing/fileURLtest.html#entry

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

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.

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

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

r=mcafee, yank the printf?

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

Removed printf, fixed comment, otherwise same.

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

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 me...sr=alecf

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

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: linux: ./netscape /home/foo/file.html *or* entering /home/foo/file.html in the urlbar win32: ./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...)

FWIW- mozilla ./test.html works for me Linux 2001112911 (Mandrake 8.1). mozilla test.html works, too, surprisingly enough...