438399 - Cannot access intranet domain when URL contains a space, when "keyword.enabled" and "browser.fixup.alternate.enabled" are enabled

Status: RESOLVED INACTIVE

(Firefox :: Address Bar, enhancement)

Description

[Timwi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0

STR: Type something like the following in the Location bar:

  domain/path/file blah

(note the space).

Reproducible: Always

Actual Results:  
Firefox visits http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=domain%2Fpath%2Ffile+blah

Expected Results:  
Firefox should visit http://domain/path/file%20blah. (If that fails, it can fall back to Google, but it must definitely first check if it's a valid URL.)

Comment 1

[Kai Liu]

This is the intended behavior.  You can, however, get the *exact* behavior that you just described in comment 0 by disabling both "keyword.enabled" and "browser.fixup.alternate.enabled" (just disabling the former will probably be enough for you, though)
<http://support.mozilla.com/en-US/kb/Location+bar+search>

Comment 2

[Timwi]

I think this should be reopened. It's not just the behaviour *I* want, I think it's reasonable for any user to expect that the browser will start by assuming you typed a URL. If the text up to the first "/" is a valid domain name, it should begin by assuming it is a domain name before trying to do anything clever. Only if the domain is not actually a valid HTTP server, it should launch a keyword search.

Comment 3

[Wayne Mery (:wsmwk)]

Timwi, Can you reproduce with version 3.6 or trunk build?

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100518 Minefield/3.7a5pre works for me with the following
bugzilla.mozilla.org/enter_bug.cgi?product=MailNews Core
both keyword.enabled and browser.fixup.alternate.enabled are true

Comment 4

[Timwi]

Still happening in 3.6.2; Firefox visits google.com and doesn’t even attempt to connect to the “domain” part of the URL.

Neither of the suggested workarounds work:

• With “keyword.enabled” set to TRUE, Firefox always contacts Google immediately, irrespective of the value of “browser.fixup.alternate.enabled”.
• If “keyword.enabled” is FALSE, Firefox never contacts Google. With “browser.fix.alternate.enabled” true, it attempts “www.domain.com”, which succeeds — this is acceptable behaviour. But with “browser.fix.alternate.enabled” FALSE, it doesn’t attempt anything else and just shows an error — expected behaviour is to search on Google.

Comment 5

[Timwi]

To make this a bit clearer...


CURRENT BEHAVIOUR (as observed by experiment):
==============================================

if (url_contains_space) {
    if (keyword.enabled) {
        contact_search_engine();
    } else {
        contact_url_as_typed();
        if (!succeeded && browser.fix.alternate.enabled) {
            contact_fixed_url();
        }
    }
}

EXPECTED BEHAVIOUR:
===================

// Do what the user says FIRST
contact_url_as_typed();

// THEN try to do something clever
if (!succeeded && url_contains_space) {
    if (keyword.enabled) {
        contact_search_engine();
    } else if (browser.fix.alternate.enabled) {
        contact_fixed_url();
    }
}

Comment 6

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.9 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

Comment 7

[Timwi]

Yes, two years after reporting, still seeing this issue. Why would it have changed if no-one made a change?

Comment 9

[Matthias Versen [:Matti]]

>domain/path/file blah

That is not a valid URL. A space is invalid in an URL since a space is a reserved character according to the relevant RFC. You have to escape the space as %20 and for a valid URL you have to add the protocol.

You are now in a grey area with 2 possibilities: This is either a URL with a space or the user wants to search and Firefox uses the last option. That is no bug and you can disable this behavior with the keyword option.

Comment 10

[Timwi]

> You are now in a grey area with 2 possibilities: This is either a URL with a
> space or the user wants to search and Firefox uses the last option.

I already addressed this above. Please read my suggestion for how I think the behaviour might be changed (comment 5). Notice the only difference is in the situation where the domain name before the first slash *does* constitute a valid server which actually responds. If the user intended it to be a search query, this is extremely unlikely to happen, so search capability is not compromised. If, however, the user intended it to be a URL, the current behaviour is severely compromising because Firefox refuses to automatically convert non-URL characters to %XX escapes (and add the protocol) despite normally having that capability.

Comment 11

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.