This is presumably part of an attempt to make sense of people typing in things like "zbarsky" in the URL bar. However, whatever was put in place to deal with that 1) Affects what happens when the user types "http://zbarsky/" in the URL bar 2) Affects the behavior of <a href="..."> links. I guess #1 is up to the app, though it seems like a bug to me. #2 is not acceptable.

It appears that this happens when keywords are enabled only. And the only reason it's not showing in Seamonkey is that they are disabled there by default. So it looks like the underlying bug has been there for about forever. That said, I think this is a very very broken behavior to be shipping...

This may be part of a problem which has caused a lot of (maybe low intensity) annoyance to many people, see Bug 231720 'Malformed URL with extra http, semi-colon, causes redirect to http://www.microsoft.com/ ("http://http://", "http:://", "http;//") because of Google "I'm feeling lucky"' Bug 231720 comment 39 and the discussion following. Whilst there are a lot of reports of 'annoyances', mainly very specific concerning the behaviour when 'typing things into the URL bar', I couldn't see an exact match to the first part of comment 0

Note that just checking for LOAD_LINK in docshell doesn't work so hot either because it still breaks scripted setting of window.location, etc. Arguably, we should have a flag to flag user-initiated loads and only those loads and only do keyword lookup for those.

this seems like something that must have been reported before.

bug 184814, I think

Indeed... Too bad that bug is dead. :( We really really should fix this. It happens for frames too: data:text/html,<iframe src="http://zbarsky/"> And I doubt sites would much appreciate us loading random data in their frames (quite apart from the security implications that that has).

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

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

From the last dup: this bug makes it possible to do some weak link spoofing, e.g. in Thunderbird or webmail.

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

A little product design judgement can go a long way here... If there are problems with Internet Keywords, maybe you should consider turning off until they are fixed. This should be done on a product-by-product basis. Mozilla: off by default. Netscape 6/7: on by default. (People had their reasons). Firefox: on by default. I think people thought it was cute at the time, but there are real IK bugs, and people file dupes pretty regularly. I'm kind of neutral here, but the feature is buggy. Thunderbird: on by default. I really don't like this. This product is going to see a lot of URL's that fail to work immediatly because email is full of internal domain and hostname-only URLs. People also have a tendency to read mail w/ while using the wrong default domain. What Thunderbird needs is a settable default domain, preferably by mail account. What you certainly do not want is any kind of cute, poorly designed, uncontrollable URL resolution. Internet Keywords (and Domain Guessing too) falls into this category. At some point, people that really understand how the browser works (like bz) should spend some time w/ interested, parinoid people (lke me), and outline a list of URL entry points, so we can properly test IK and DG. Until that happens, perhaps we shouldn't continue to leave it on w/o thinking about what the risks are.

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

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

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

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

I think we need to clean this up. Boris, any ideas as to who would be a good candidate to fix this?

Boris, if you could try the patch I've just attached to bug 263213 (of which this bug is probably a dup) and see if it helps.

James, that patch just disables keywords completely. That's fine by me, of course. But if that's what we're doing we should remove the code, not just leave dead code in the tree.

Mike, I don't see how anyone can fix this until we figure out what behavior we do want.

So, based on super-quick testing, keyword.enabled only disabled the auto-pseudo-fixup, but entering keyword:foo still works. Based on that, I think the solution is as follows: default keyword.enabled to false. add a new pref called keyword.urlBarFixup, default to true. For text entered in the URL bar (i.e. if you hit enter/click Go) we can do the following checks. If there is a scheme, clean up and try to handle using that scheme if it seems to be a local file, handle that if it has spaces, pass to IK (keyword:<typed string>) if there is a period in the string, try to resolve if it has no scheme and no periods, pass to IK (keyword:<typed string>) I think this generally addresses the problem, without really breaking the ability to fix up typed strings. -> dietrich for now, pending feedback

(In reply to comment #20) > default keyword.enabled to false. > add a new pref called keyword.urlBarFixup, default to true. > For text entered in the URL bar (i.e. if you hit enter/click Go) we can do the > following checks. > > If there is a scheme, clean up and try to handle using that scheme > if it seems to be a local file, handle that > if it has spaces, pass to IK (keyword:<typed string>) > if there is a period in the string, try to resolve > if it has no scheme and no periods, pass to IK (keyword:<typed string>) > > I think this generally addresses the problem, without really breaking the > ability to fix up typed strings. Local servers (no dot) will not resolve in this setup. A search domain is not required if your local DNS resolver can resolve local records. DNS must be checked first. -david

We may want to resolve this FIXED based on the checkin in bug 331522. From the original report, issue #2 has been fixed. Issue #1 still happens, but only if zbarsky is not resolvable as a host name. I'll let Boris decide.

Probably worth resolving this and filing a followup bug on the http://something/ issue (which I still think is a bug, but have no idea how to resolve given URI fixup; perhaps we'd need to track fixup information on URIs or move the keyword lookup up to a level where we're not dealing with nsIURI objects yet...).

(In reply to comment #23) > Probably worth resolving this and filing a followup bug on the > http://something/ issue (which I still think is a bug, but have no idea how to > resolve given URI fixup; perhaps we'd need to track fixup information on URIs > or move the keyword lookup up to a level where we're not dealing with nsIURI > objects yet...). > Local networks can resolve that. In addition, <a href="http://something/file.txt">file on something</a> is perfectly reasonable.

Sure. My point is that if "http://something/file.txt" does NOT resolve we'll do a search for "something" on google instead of giving an error page. We should be giving an error page.

(In reply to comment #25) > Sure. My point is that if "http://something/file.txt" does NOT resolve we'll > do a search for "something" on google instead of giving an error page. We > should be giving an error page. > Ahh, ok. Yes, I agree. An error page over a search of something that might not warrant a search.

The issue in the summary was fixed by roc in bug 331522. I filed bug 332962 for the remaining issue from comment 0.

Adding fixed1.8.1 since bug 331522 fixed this on the branch as well.

The entire idea of having internet keywords fire when a the location bar's URL errors is sort of passe. It too often sends hostnames that people might not want to reveal to the keywords's search engine (google). And the idea that people would type inline non-url junk to get a search result, well we have the second, in-toolbar search window now. If you compare the Netscape 6/Mozilla 0.9.2 design, we had many strange and beautiful ways to accidentally search, but no simple and easy way to search. Removing many of these old hooks is probably a natural extension of the simple-is-beautiful philosophy of Firefox and friends. I'll try to find some time to poke around and test this in all the products and update the keyword documentation.

(In reply to comment #29) > The entire idea of having internet keywords fire when a the location bar's URL > errors is sort of passe. You'd prefer a "Host not found" error page? > And the idea that > people would type inline non-url junk to get a search result, well we have the > second, in-toolbar search window now. Why have two address bars. It makes little sense. 1) Do a DNS request for the address, spaces and all. 2) When it fails, send the query to the users designated search engine. Seems simple although I know it isn't. -david

"You'd prefer a "Host not found" error page?" Yes, one that looks like this: /!\ Server not found Product can't find the server at something. * Did you mean something.com? <- links to http://something.com/ * Did you mean to search for something? <- links to Google search * Check the address for typing errors such as ww.example.com instead of www.example.com * If you are unable to load any pages, check your computer's network connection. * If your computer or network is protected by a firewall or proxy, make sure that Product is permitted to access the Web. [ Try Again ]

(In reply to comment #31) > "You'd prefer a "Host not found" error page?" > > Yes, one that looks like this: > > /!\ Server not found > > Product can't find the server at something. > > * Did you mean something.com? <- links to http://something.com/ > > * Did you mean to search for something? <- links to Google search > > * Check the address for typing errors such as > ww.example.com instead of www.example.com > > * If you are unable to load any pages, check your computer's network > connection. > > * If your computer or network is protected by a firewall or proxy, > make sure that Product is permitted to access the Web. > > [ Try Again ] > That'd be ideal.

(In reply to comment #30) > 1) Do a DNS request for the address, spaces and all. > 2) When it fails, send the query to the users designated search engine. Sounds like the intention of bug 245597.

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

I encountered this trying to make a link to about:blank. It turns out that in Chromium, http://about:blank works instead of doing a search. That'd be nice since I have a use case in a project's HTML documentation for directing developers to that tab. I see bug 263213 was resolved some time ago. This issue here feels like a long-standing but neglected continuation of that.

BTW in Chromium, that about:blank link has the usual 'open' options instead of silently doing nothing.