290782 - URIs passed to firefox lacking http:// fails

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P2)

Description

[Thomas K. (:tom)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050417 Firefox/1.0+

in mIRC, clicking urls lacking a http:// fails.  in other programs (tested in
MSN 7) it doesn't.

tests:
* open "www.google.com" in run menu, success
* open "http://www.google.com" in run menu, success
* open "firefox www.google.com" in run menu, failure, result:
The file /C:/Documents and Settings/Tom/www.google.com cannot be found. Please
check the location and try again.

This is because urls passed to firefox directly (as mIRC does, because it used
to always pass them to IE directly and there was some registry hack to fix that,
now it's fixed in 6.16 and passes directly to the default browser instead of to
windows which would then pass it properly) which lack an http:// fail.


Reproducible: Always

Steps to Reproduce:
1. Open Start > Run
2. type "firefox www.google.com"
3. Get error message/page

Actual Results:  
shows error

Expected Results:  
append http:// and go to google

Thanks for the help of jesus_X and sp3k while filing this bug.

Thanks to Wolf for catching that this is a regression caused by bug 276588.

Comment 1

[Tuukka Tolvanen (sp3000)]

* If mIRC makes the judgement in its domain of expertise, irc content, that
www.google.com should be presented as a http link, but then passes it on to a
handler bare without specifying the http bit, relying on the handler to make the
same guess about its nature without the context that mIRC had to make that
guess, that's a bug in mIRC and should be fixed, regardless of what firefox does.

* I hear that Start -> Run |iexplore www.google.com| goes to google, so IE
parity would be to do the same.

* I'd prefer |firefox nonexistentfile| on the command line to act predictably
and fail, rather than go play with DNS, to be consistent with the common pattern
of non-option arguments being file names.

Comment 2

[Thomas K. (:tom)]

I just thought this thought provoking line would be useful to all parties:

[01:17:21] <Jesse> i saw code in mozilla that was supposed to notice that
there's no file called www.X.com and treat it as a URL instead of a filename

Comment 3

[Benjamin Smedberg]

non-option arguments to firefox are treated as URLs relative to the current
working directory. So we actually try to load
file:///C:/Current/Directory/www.google.com which of course doesn't exist.

Comment 4

[Darin Fisher]

I think firefox 1.1 will be blamed for breaking links like "www.foo.com" from
other applications.  This will be a pain point as we may not have the luxury to
expect other applications to be fixed.

Comment 5

[Asa Dotzler [:asa]]

we'll evaluate for 1.8b4. if it doesn't make that train, it doesn't make 1.1.

Comment 6

[Darin Fisher]

bsmedberg:

How about we try treating the argument as a relative file URL, and if that does
not identify a file, then we try loading it by slapping http:// in front of it?
Does that sound reasonable?

Comment 7

[Benjamin Smedberg]

Well, "~/www.mozilla.org" does identify a file, it's just that the file doesn't
exist. Remember that this API isn't just for firefox, when composer uses it you
might be able to expect

./nvu myfile.html (which doesn't exist) to continue to work. So a simple
nsIFile.exists check won't work.

So I expect we need a smarter mechanism that looks for common
prefixes/suffixes/multiple dots/something. Although I didn't expect this
particular problem, this is one of the reasons I made the
nsICommandLine.resolveURI function, to encapsulate any interesting 

Comment 8

[Darin Fisher]

Is there no way for the browser to inject a command line handler that would
inspect the relative URI and determine that it should be handled as a http://
instead of as a relative file URI?

Comment 9

[Benjamin Smedberg]

That is possible, we could just put a helper function in nsBrowserContentHandler
that does multi-part resolution.

Comment 10

[Justin Kerk]

Whatever heuristic gets used doesn't have to be very clever, because the main
source of the issue is programs like mIRC that pass in links that they
themselves have heuristically detected. As far as I can tell the only
protocol-less links that mIRC detects are those starting with "www." or "ftp.",
for example.

Bizarrely enough, IE seems to consider _anything_ without a path to be a
hostname; try running "iexplore example.com", "iexplore example.tld", "iexplore
example" or even the name of a filename that exists in the current working
directory. It probably relies on Windows Explorer associations always passing it
a fully qualified path for local files. So basically anything Firefox implements
would be smarter than what IE does.

Comment 11

[Thomas K. (:tom)]

Attachment: Flash 8 beta post-install page launch

Flash 8 beta installer, after it finishes installing, sends me back here.  It
forgot to pass the http:// as well, I guess.  Not terribly sure why, though.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050715
Firefox/1.0+

Comment 12

[Benjamin Smedberg]

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

Comment 13

[Benjamin Smedberg]

Attachment: Use heuristics if the file doesn't exist, rev. 1

Comment 14

[Jesse Ruderman]

I think it would be more sane, and possibly more secure, to require a
command-line flag (such as -file) before local filenames.  I don't like the way
a typo in a filename could take you to a website when you're trying to open a
local file, and a stray local file could take you to a local file when you're
trying to open a website.

Comment 15

[Darin Fisher]

jesse: that is a good idea.  we should similarly have a -url command line flag.
 then, we'd want to make sure that -url is used when ShellExecute is called by
some other application.

Comment 16

[Benjamin Smedberg]

Jesse, I consider this entirely a backwards-compatibility hack for xchat and
others who are bogusly calling "www.mozilla.org" intead of
"http://www.mozilla.org". There are lots of old behaviors that we have to
continue to support.

Comment 17

[Justin Kerk]

I'm not familiar with the Mozilla APIs, but it looks like that code would stick
http:// onto URIs that start with ftp, which is probably not what we want.

Comment 18

[Darin Fisher]

Comment on attachment 189804 [details] [diff] [review]
Use heuristics if the file doesn't exist, rev. 1

>Index: browser/components/nsBrowserContentHandler.js

>+  if (! uri instanceof nsIFileURL) {
>+    return uri;
>+  }
>+
>+  try {
>+    if (uri.QuerInterface(nsIFileURL).file.exists())
>+      return uri;

If "instanceof" returned true, then |uri| is already QI'd to
nsIFileURL for you.  There is no need to QI again.


>+  if (aArgument.match(/^(www|ftp)\.([a-z0-9]+\.)+[a-z]{2,5}(\/|$)/)) {
>+    var io = Components.classes["@mozilla.org/network/io-service;1"]
>+                       .getService(nsIIOService);
>+
>+    try {
>+      uri = io.newURI("http://" + aArgument, null, null);
>+    }

For "ftp." wouldn't you want to prepend "ftp://" instead of "http://"?
Have you considered using the URL bars fixup code?  see nsIURIFixup.

Comment 19

[Benjamin Smedberg]

Attachment: Use heuristics if the file doesn't exist, rev. 1.1

It turns out the instanceof thing was due to the "!" operator binding more
tightly than "instanceof", so it was doing "false instanceof nsIFileURL".

Comment 20

[Darin Fisher]

Comment on attachment 190419 [details] [diff] [review]
Use heuristics if the file doesn't exist, rev. 1.1

>Index: browser/components/nsBrowserContentHandler.js

>+  // We have interpreted the argument as a relative file URI, but the file
>+  // doesn't exist. Try URI fixup heuristics: see bug 290782.
>+
>+  if (aArgument.match(/^(www|ftp)\.([a-z0-9]+\.)+[a-z]{2,5}(\/|$)/)) {
>+    var urifixup = Components.classes["@mozilla.org/docshell/urifixup;1"]
>+                             .getService(nsIURIFixup);
>+
>+    try {
>+      uri = urifixup.createFixupURI(aArgument, 0);
>+    }
>+    catch (e) {
>+      Components.utils.reportError(e);
>+    }
>+  }

I don't understand.  Why does the string have to start with ftp.
or www. in order to go through URI fixup land?	I'd just pass it
to createFixupURI we couldn't get a file URL from it.  What's the
harm of doing that?  With the current code, we have URI fixup
rules in two places, and that doesn't seem so good.

Comment 21

[Benjamin Smedberg]

Do you want to pass "index.html" through uri-fixup? I don't think it will give
us what we're looking for, though if the file doesn't exist I'm not sure it matters.

Comment 22

[Darin Fisher]

Exactly.  I'm concerned with "cnn" and such.  Basically, URLFixup is what we do
to correct things entered into the URL bar, and I would think that we should
treat the command line like the URL bar (with the exception of trying to match
relative file paths first).  I see that you are disallowing keyword lookup and
the alternate URI feature... hmm...

Comment 23

[Andrew Schultz]

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

Comment 24

[Benjamin Smedberg]

OK, I'm not sure I like this: if I use urifixup unconditionally with a missing
"index.html", urifixup succeeds with the URI "http://www.index.html".

Comment 25

[Justin Kerk]

Well, FF 1.0 invoked with a non-existent "index.html" tries to look up
"www.index.html" so we've been doing that for some time already....

Comment 26

[Darin Fisher]

bsmedberg: i'm just arguing for consistency between the command line and the url
bar.  maybe that's not desirable?

Comment 27

[Benjamin Smedberg]

Attachment: Use heuristics if the file doesn't exist, rev. 1.2

ok, I'll capitulate ;-)... it's no worse and quite a bit better than 1.0 was.

Comment 28

[Chase Phillips]

Comment on attachment 191396 [details] [diff] [review]
Use heuristics if the file doesn't exist, rev. 1.2

a=[e-mail]

Comment 29

[Benjamin Smedberg]

Fixed on trunk for 1.8b4

Comment 30

[Adam Guthrie]

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