280854 - Search cannot be disabled or avoided for one-word URLs when a proxy is configured in Firefox 1.0

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Vassily Goissa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Keyword or other type of search is performed for all forms of one-word URLs
("any" or "http://any" and even "http://any/") if a proxy is configured.
"keyword.enabled" and "keyword.URL" settings are both ignored, as well as
"browser.search.selectedEngine" and "browser.search.defaultenginename". The URL
prefix used for search is "http://www.google.com/search?q=". Quite annoying,
since I have to type FQDN to reach frequently used sites in my domain.

Reproducible: Always

Steps to Reproduce:
1. configure the browser to use a proxy for http.
2. go to 'any' or 'http://any' or 'http://any/' URL
3. if not satisfied already try to change "keyword.enabled" or "keyword.URL" or
"browser.search.selectedEngine" or "browser.search.defaultenginename" and go to (2)

Actual Results:  
browser was directed to "http://www.google.com/search?q=any"

Expected Results:  
go to "http://any/" URL and be presented with the site or relevant error message
returned by the proxy(or the browser if the proxy is dead) if keyword search is
either disabled(required, MUST work this way) or enabled(optional, but should be
the same since it is impossible to positively determine if the site does not
exist when using a proxy=no DNS lookups). Probably the preference settings can
be enhanced to make the behavior really configurable, i.e. triple-state
enabled=always do keyword search,disabled=never do keyword search and auto=do
keyword search only if text is positively not a valid URL: is not a (java)script
command, contains spaces or other illegal chars or DNS fails.

no other dependencies found(i'm using the default theme).

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Wow, that's an old one :).

*** This bug has been marked as a duplicate of 2875 ***

Comment 2

[benc]

REOPEN:
This bug is probably the opposite of that bug.

That bug was silently fixed in Firefox-only, or this is a proxy behavior.

Can you try the same URL w/ Mozilla or IE?

Comment 3

[Vassily Goissa]

(In reply to comment #2)
> Can you try the same URL w/ Mozilla or IE?
I can do that in opera using same proxy - it's not the proxy problem, trust me :)
Seems to be a side effect of quick fixes of keyword search not working through
proxy. FF Does not check the user setting for keyword search. Also this can be
judged as an error of algorithm guessing validness of URL. But something like
"any text" does trigger the keyword search...
I have no Mozilla to try this in, but Netscape 7.0 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208
Netscape/7 has the same effect as FF 1.0

Comment 4

[Vassily Goissa]

(An addition to reply to comment #2)
I was a bit too rough with "FF Does not check the user setting for keyword
search." The case is only with single-word URLs, and it does not follow any
keyword search rules anyway-the prefix is fixed. Maybe there are two
url-validating stages/functions? Haven't seen the source, just guessing.

Comment 5

[Vassily Goissa]

(In reply to comment #4)
Finally I've read through the 2875 - definitely this is a side effect of a
related bugfix. Probably 245597 or similar. 269519 is also related to this
stuff, but from the other side.
Bad thing is that the offending action is performed somewhere AFTER parsing the
contents of the address bar - effects of "word" "http://word", "http://word/"
and "http://word:80/" are identical. This is absolutely not acceptable. if one
has spent time typing in all the optional URL parts then it is a sure sign that
no help is required in finding the site.
https makes some funny result - tries to access
"https://http://www.google.com/search?q=www/" in response to "https://www/". FTP
and GOPHER act as if it was HTTP (not that I'm using that, but for complete picture)
URLs that match the "bypass proxy" list are not affected as well - those are
treated as expected: DNS => keyword if needed.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

*** This bug has been marked as a duplicate of 269519 ***

Comment 7

[benc]

REOPEN again, b/c I still don't think this is a dupe of a problem in core.

First, does this happen in firefox only, or firefox and mozilla? (This is easier
than telneting to the proxy).

Second, do you have the log entries for your proxy?

Comment 8

[Vassily Goissa]

Must have been a prolonged stupidity attack - my proxy settings were the cause
of the problem... Thanks for drawing my attention to the log :)
Sorry for wasting your time...