On Win95, using M10 (build 1999100618), attempting to replicate the behaviour of Bug 11362, I entered into the location bar: http://http://127.0.0.1/ Rather than the behaviour noted in Bug 11362 (an endless nonproductive throbbing), the location bar updated itself to: http:0//http://127.0.0.1/ and then to http://www.http.com:0//127.0.0.1/ at which point it stopped. No new page loaded, no activity was noted in the server logs for 127.0.0.1 , no error message. It seems likely that this problem is really cross-platform. This problem is reproducible with other valid URLs prepended with an extra http:// . To replicate: Follow the example above.

The exact same behaviour occurs with M11 build 1999101109 on WinNT.

Claudius, do you know anyone is taking care of this? I am not sure who should be responsible for.

reassign it to don.

I don't think this is an xpapps problem. I would guess it's a Necko and/or webshell(?) thing. So I'm going to change the component, reassign to gagan and cc' travis in hopes that someone will want to own this bug. sorry for the delay

this is webshell. The url parsing is working correctly, but the subsequent decisions that we make on not finding a URL's host (in this case http) are made there (including the one to slap www. and .com around it) The :0 should be fixed from my recent changes. basically with those changes you will get an error when you try to create a URI out of this kinda string. Even though this happens in webshell, I am not sure how we want to handle cases like these. Since http could very well be a host in someone's intranet in which case this is doing the right thing. Anyhow assigning to travis...

Jud was the one in there just very recently making these changes. Of course if this isn't a big thing, all this code will be changing with the landing of URI Dispatching.

"http.whatever.tld" could indeed be a valid domain name, but a http:-scheme URL for that would be "http://http.whatever.tld", quite different from "http://http://whatever.tld". If someone created a "http.whatever.tld" presumably they would type "http://http.whatever.tld" to access it. (Trying... editing hosts file... yes, this works with Mozilla at present). The simplest way to handle this that I can think of would be to excise any "http://" substring that does not occur at the beginning of the string typed into the location bar, before doing any of the autocomplete or any other URL processing. I can't think of a case where "http://http://" would be meaningful, and I am pretty sure that it is illegal according to RFC1738, the URL spec: <URL:ftp://venera.isi.edu/in-notes/rfc1738.txt>. For that reason, it isn't reasonable to expect the autocomplete code to handle it, which is why it makes sense to get rid of the extra "http://" before doing any other processing on any URL typed into the location bar (only) - or not at all. The only other reasonable alternative would be to say WONTFIX. This is really a User Experience enhancement for those who don't completely rely on URL autocompletion. It would only help when they've made a mistake, so strictly it isn't Mozilla's problem, but it would be a useful enhancement. The only scenario where this happens is when an interruption happens as a person is just beginning to type a URL into the location bar, and an interruption happens before the rest of the URL is typed. Most people will keep typing when interrupted until the end of the "word" they are typing, but may not remember that they did so when they resume typing. This happens to me personally at least once a week If this duplicate deletion does get done before anything else, changes in URI code probably don't make any difference (not that this is a big thing). Finally, if this is worth doing, it may be worth doing right: rather than just catching "http://http://", it may make sense to fix all "scheme://scheme://" - or at least "ftp://ftp://" as well. Also, while there is no host called "www.http.com" (or "http.com"), "http.com" does exist and is registered to General Hypertext, 2327 W McLean #2F, Chicago, IL 60647 If a legitimate webserver were put up at "www.http.com" user error would flood it with unwanted GETs as things stand. And, if a scam artist got control of http.com, would we really want to send traffic their way?

Ah, I missed a subtlety. "http" as an intranet server could be accessed as "http://http/" and, at that, "http://http:/" could (should?) equate to "http://http:80/" and thus be valid - but that's still not "http://http://" It still looks like the way to do this is to replace (exact, case insensitive, regex) "^http://http://" with "^http://" (a second "http:// could be valid later in the URL after a ?) before doing any other transformations. It would be simple to do, useful, and I can think of only one downside: Yes, that hoses the guy who *does* set up an intranet host "http", types "http://http", adds in ":" but forgets to put in the port number, and then mistakenly types "//" instead of "/", and then types [Enter], and no, why should anyone care? {Summary changed: -"invalid URLs a la Bug 11362" +"doubled initial http://"}

is this still a problem? I just tried entering http://http://127.0.0.1/ in teh url bar and it did the right thing (nothing)?

"Does Nothing" does not seem reasonable for "http://http://whatever" - if it cannot or will not be silently fixed, it should result in an alert of some kind, so the user does not keep trying and get annoyed. Silent fixing makes more sense to me, but an alert would be ok - although, since this would require recognizing the user error, it would probably be as easy to fix the error as report on it. As a general rule, any user-entered URL starting with some valid scheme should result in *some* feedback, IMHO. As it stands, it looks like "http://http://127.0.0.1/" is being mapped to null, likely causing the javascript error showing on the console: ------------------------------------------- ****** GENERAL DRAG ******** Parse Time (this=014F8320): Real time 0:0:0, CP time 0.010 DTD Time: Real time 0:0:0, CP time 0.000 Tokenize Time: Real time 0:0:0, CP time 0.010 Parse Time (this=014F9790): Real time 0:0:0, CP time 0.000 DTD Time: Real time 0:0:0, CP time 0.000 Tokenize Time: Real time 0:0:0, CP time 0.000 Parse Time (this=014F9870): Real time 0:0:0, CP time 0.010 DTD Time: Real time 0:0:0, CP time 0.010 Tokenize Time: Real time 0:0:0, CP time 0.000 FindShortcut: in='http://http://127.0.0.1/' out='null' Parse Time (this=014F9870): Real time 0:0:0, CP time 0.010 DTD Time: Real time 0:0:0, CP time 0.000 Tokenize Time: Real time 0:0:0, CP time 0.010 JavaScript Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a [nsIBrowserInstance.loadUrl]" nsresult: "0x804b000a (<unknown> )" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserLoa dURL :: line 1064" data: no] ------------------------------------------- I'd still recommend filtering "^http://http://" to "^http://" (or "^scheme://scheme://" to "^scheme://" - looping through a list of all the schemes Mozilla knows) before doing any other URL parsing (for Location bar input only) as a way of validating the user-entered data the url parser has to contend with while improving the User Experience. Tested with: 1999-11-29-08-M12 nightly binary on Windows NT 4.0sp3

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

This is such an edge case that if the user enters a double scheme url and nothing happens (which is the case right now), he'll verify the string. I don't think it's worth the string traversing to check for this case. If someone still wants us to "handle" this case, please reopen the bug and mark it m20 and severity = enhancement.

I'm going mark this VERIFIED. I believe the only issue left is the silent failure. AFAIK we aren't doing any kind of elegant error handling yet(from a user perspective) so as long as this case is dealt with when we do all of the other errors there should'nt be a major problem.

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

Quoting davidr8@home.com from bug 29740, "no error message on malformed hyperlinks (http://http://)", > if a user clicks a link like http://http://www.amazon.com/, mozilla does > nothing at all, which is very frustrating because it seems to be ignoring > you. an error page would be nice, or maybe a dialog "the link you clicked > is messed up, but mozilla thinks it knows what the link was supposed to be. > click continue to go to http://www.amazon.com." Either something like that or a silent fix would be preferable to a generic error message. REOPENing as an enhancement request.

I wasn't saying that an all encompassing error message would be okay for this I was jsut saying that (at the time) we didn't have *any* error messages. We barely have any now. Mozzilla fails silently for all manner of things. If you want this to be the bug for "there should be an error message for failure xxx" where xxx is the original incarnation of this bug then fine. handing off QA

Current build (03-04-00) on linux gives the javascript error in a message box, it does no longer silently fail: JavaScript Error: uncaught exception: [Exception... " 0x804b000a [nsIBrowserInstance.loadUrl]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserLoadURL :: line 839" data: no] Maybe we need some better mapping of this kind of errors.

Current status: Without keyword search activated this pops up an message box that it was unable to find http://www.http.com. With keyword search it ends up on www.w3.org, interesting choice When there is a intranet host named http it gets you now a 404 that it was unable to find the directory /127.0.0.1/. I think this one can be closed ...

why is the keyword search activating with a "url" that starts with "http://"?

mass move, v2. qa to me.

Is networking considered the right component? If we support mapping <scheme>+ ":" + <noPORT> to <scheme> + ":" <defaultPORT>, and "//" is a valid URI, then this is a valid URL. If "//" is an invalid URI (Comm 4 does a GET with it...), then we should error. Users that are using hostnames instead of fqdns (e.g, me creating a work system called http.mcom.com), or this person who owns www.http.com should be connected these URLs. If we do not like the idea of someone getting accidental traffic from the browser because they registered a URL scheme, we should get rid of this "web-berize" non-FQDN's by making them into "www." + <honstname> + ".com" feature, which I have never liked. We should NOT start contemplating changes that transform legal hostnames and fqdn handling into a pile of non-conformant exceptions. I think the best example of this the feature where Netscape had imbedded special DNS handling of certain domains (like www.netscape.com) so that it could support a larger than normal list of host IP addresses. (I'd include the link, but I can't seem to find any reference to this feature on *.netscape.com). Anyhow, the point is: once we start creating a lot of weird exceptions, there is no limit. I'd like to mark this RFE as RESOLVED/INVALID, but I'm going to wait for some feedback.

-> URL bar. I don't think anyone in necko came close to fixing this in the URL functions, esp since the example is bascially a valid URL to: scheme = http: hostname = "http" -> http.localdomain or www.http.com port = 0 (: w/o port is silently discarded) URI = everything else.