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

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Tobias Burnus]

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.

Comment 1

[sairuh (rarely reading bugmail)]

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

Comment 2

[sairuh (rarely reading bugmail)]

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

Comment 3

[Claudius Gayle]

nav triage team: nsbeta3-

Comment 4

[sairuh (rarely reading bugmail)]

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

Comment 5

[Viswanath Ramachandran]

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

Comment 6

[Marcia Knous [:marcia]]

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

Comment 7

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 8

[Brian Z]

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

[timeless]

we're friendlier on windows.

Comment 10

[sairuh (rarely reading bugmail)]

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

Comment 11

[Doug Turner (:dougt)]

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

Comment 12

[sairuh (rarely reading bugmail)]

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!

Comment 13

[Doug Turner (:dougt)]

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

it is a frontend problem.  

Comment 14

[timeless]

so uriloader?

Comment 15

[Doug Turner (:dougt)]

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

Comment 16

[Robin Green]

/home/dougt indicates file:, home/dougt indicates http:

Comment 17

[Doug Turner (:dougt)]

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

Comment 18

[Robin Green]

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

[Doug Turner (:dougt)]

chris, uriloader is the right place for this bug.  

Comment 20

[sairuh (rarely reading bugmail)]

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

[Doug Turner (:dougt)]

-> uriloader

Comment 22

[sairuh (rarely reading bugmail)]

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

Comment 23

[benc]

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

Comment 24

[sairuh (rarely reading bugmail)]

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

Comment 25

[Aaron Kaluszka]

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

Comment 26

[benc]

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

[Gilles Durys]

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

Comment 28

[Rein Smedinga]

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

[Gregor Rosenauer]

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

[benc]

Please create a new bug for that problem.

Comment 31

[Akkana Peck]

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

Comment 32

[Akkana Peck]

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

[Akkana Peck]

Timeless tells me that it doesn't work on Windows now either.  All/All.

Comment 34

[benc]

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

Comment 35

[Jeremy M. Dolan]

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

[Akkana Peck]

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.

Comment 37

[Akkana Peck]

Attachment: Proposed fix

Comment 38

[Jeremy M. Dolan]

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

[timeless]

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

[Mike Kaply [:mkaply]]

As timeless said

Please make it

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

Comment 41

[Xan Lopez]

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

Comment 42

[Akkana Peck]

Attachment: Revised patch, XP_WIN || XP_OS2

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

Looking for review ..

Comment 43

[Chris McAfee]

r=mcafee, yank the printf?

Comment 44

[Akkana Peck]

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

Comment 45

[Akkana Peck]

Attachment: one more version

Removed printf, fixed comment, otherwise same.

Comment 46

[Akkana Peck]

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

Comment 47

[Akkana Peck]

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

[Alec Flett]

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

seems quite reasonable to me...sr=alecf

Comment 49

[Akkana Peck]

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

Comment 50

[Jeremy M. Dolan]

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

[Akkana Peck]

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

Comment 52

[[not reading bugmail]]

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

[Akkana Peck]

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.

Comment 54

[[not reading bugmail]]

ok, here is probably what seems to fix the folders in bug 111018 comment #5

Comment 55

[benc]

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.

Comment 56

[sairuh (rarely reading bugmail)]

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.

Comment 57

[benc]

New bug for relative paths?

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

Comment 58

[hans_k_97]

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

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