693530 - URL with spaces treated as keyword.URL search

Status: RESOLVED DUPLICATE of bug 690307

(Firefox :: Address Bar, defect)

Description

[Jim]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

Enter a URL in the Location Bar (typed, copy/pasted, or directly from Bookmarks/History dropdown selection) which meets the following criteria:

1. Contains literal (NOT encoded as %20) spaces
2. Hostname is not a FQDN (e.g., an intranet site)
3. Is not prefixed by protocol (e.g., http://)


Actual results:

Firefox treats this as a keyword.URL search.


Expected results:

Firefox should attempt to load the address as it was given.

I understand some may argue that "URL spaces should always be encoded;" however, I believe this behavior to be a regression vs. previous versions.  Furthermore, for usability's sake, I see no reason for this not to work -- Firefox could just encode the URL "under the hood" -- especially considering it worked in previous versions.  IMHO possibly related to implementation of protocol prefix hiding, but this is speculation.

Comment 1

[Matthias Versen [:Matti]]

>2. Hostname is not a FQDN
That is not enough. You have to forget the dot at the end.
"server./example a" works but "server/example a" not.

The heuristic can't work in all cases and you have to meet 4 conditions to trigger this issue. (invalid URL with space, FQDN missing, dot missing, protocol missing)
What you really want is to disable the keyword search -> http://support.mozilla.com/en-US/kb/Location%20bar%20search

Comment 2

[Jim]

Thanks for replying Matti, but I don't think this is resolved.

- This IS a change vs. past behavior: Location Bar is now STRIPPING the protocol specifier, when I select a URL from my Bookmarks and History - this is probably what triggered this issue.  I emphasize that this is a change vs. previous versions because a specific sequence of actions that used to work, no longer does.

- There is no conceivable reason why choosing a Bookmark or History item from my "AwesomeBar" results should fail; if I explicitly pick what Firefox clearly recognizes as a Bookmark (or History), and loading that Bookmark (or History) fails, this is a problem.

- Adding a trailing dot does NOT resolve the issue; adding a dot just "turns" the name into a FQDN.  I explicitly stated I'm talking about NON-FQDNs, such as HOSTnames on a LAN or intranet.  Adding the dot does not fix it, in fact it makes it worse because Firefox (rightly!) assumes "<hostname>." is a FQDN now, which generally is not going to be in DNS.  Hostname != FQDN.  Adding a dot doesn't magically transform an internal hostname into a resolvable FQDN.

- No, what I really want isn't to disable keyword.URL searches, that is a feature I use often and shouldn't be mutually exclusive with this function.  There isn't any reason to sacrifice this feature.  Firefox just needs to recognize when you are selecting a Bookmark or History item, particularly considering it itself is telling you "here, this is a Bookmark" or "here, this is a History item."

- I agree if the address the user enters is not a Bookmark or History item and there's no match against these "known" addresses, there's no way for Firefox to know that this isn't a keyword.URL search.  But it's silly to treat a click on a Bookmark or History as anything other than a click on a Bookmark or History.

Furthermore, this problem still occurs if an item is saved with %20 encoding!  E.g., a Bookmark SAVED AS "hostname/sdfsdf/Special%20Offers.html" triggers the issue when you select it (either by keyboard or mouse) when it's produced by the Location Bar.

Comment 4

[Tom Wardrop]

I'd encourage developers or otherwise key decision makers to read my bug report for alternative information on this issue. The main problem I've encountered is that the manipulation of the URL in the location bar introduced in recent versions of Firefox as an attempt to make URL's more readable, directly conflicts with the keyword search features. It makes valid, unambiguous URL's into strings which Firefox doesn't recognise as URL's.

As mentioned in a previous reply, there are 4 checks performed when determining whether or not a string is a URL of a search phrase. To repeat the list, they're: invalid URL with space, FQDN missing, dot missing, and protocol missing. At a glance, it seems reasonably unlikely that someone would miss out all four of these requirements for URL detection, and it would subsequently seem unreasonable to expect Firefox to know it's a URL, so you may assume that Firefox is doing the best it can. That list however, thanks to Firefox's URL rewriting which removes the protocol and character encoding, is reduced to only two, FQDN missing and dot missing. All of sudden it becomes very easy for Firefox to misinterpret a URL as a generic search phrase.

The fix is to either remove Firefox's character encoding substitution or protocol stripping behaviour, or add a 5th check which assumes any valid hostname or FQDN directly followed by a forward slash, to be a URL. At the moment it seems non-FQDN's such as localhost are looked up when they're on their own (e.g. typing 'dog' into the location bar first looks up the domain 'dog'), so that behaviour is fine, but as soon as you introduce invalid characters after that like unencoded space characters, it assumes it's a search term. Point being that adding that 5th check should solve the problem completely.

Comment 5

[Tom Wardrop]

I should have mentioned that some other URI schemes which don't use forward slashes (like LDAP; just an example) will still suffer from the problem even with the suggested 5th check.

Comment 7

[Jim]

Tom, rather than either of those fixes, couldn't the code just have a check "is this in Bookmarks or History" and if so, open that URL?  Although I guess that wouldn't work in Private Browsing, or any other time History is disabled.

Comment 8

[Tom Wardrop]

Ideally, the heuristic should be able to pickup all valid URL's. If anything makes it through the heuristic, then in theory it should NOT be in history or as a bookmark. If it is in your history or bookmarks, then the heuristic isn't doing its job properly and maybe an additional conditions needs to be added assuming it's not too ambiguous.

Comment 9

[Jim]

Has this gotten any serious attention?  Any plans to fix?

Comment 10

[Tim (fmdeveloper)]

This looks to be a duplicate of Bug 438399, no?

Comment 11

[Jim]

Hmm, it does look like it might be a duplicate report of that behavior, although I certainly don't believe I experienced this issue prior to Firefox 7.  In fact I have several bookmarks with spaces in the URL, which worked before, and don't work anymore (still broken in version 9).

Does Bug 438399 occur in 3.6 even if the URL in question is accessed thru a bookmark?

Comment 12

[Filipus Klutiero]

I guess not. But this is a duplicate of #690307.