Bug 140057 - Non-Google URL brings up Google page
Non-Google URL brings up Google page
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Depends On:
  Show dependency treegraph
Reported: 2004-11-19 10:58 EST by Andre Robatino
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 23:44:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2004-11-19 10:58:30 EST
Description of problem:
  Entering the following URL


triggers a Google search of a garbage string, instead of the desired URL.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Enter URL <https://www.accountonline.com/AC/> (without the brackets).
Actual results:
  Google search for garbage string.

Expected results:
  Correct Web site (AT&T Universal Card).

Additional info:
  Not using any funny settings.  Another person using FC3 on a
different machine confirmed the behavior.
Comment 1 Michael Brown 2004-11-19 14:28:10 EST
The remote site is returning:
HTTP/1.1 302 Found
Server: WebSphere Application Server/5.1
Content-type: text/html;charset=ISO-8859-1
Location: http://wermi15avip:1110/View?docId=Index&siteId=AC
Content-language: en
Transfer-encoding: chunked
Via: 1.1 S1PS
Date: Fri, 19 Nov 2004 14:15:12 GMT

wemi15avip is not a valid fully-qualified domain name. So Firefox is
trying to be helpful by doing a google search on the result.

You can change this behaviour by setting keyword.enabled to false in
the user preferences.
Comment 2 Andre Robatino 2004-11-19 14:59:16 EST
  Using about:config, I set both keyword.enabled and
browser.fixup.alternate.enabled to false.  Still doesn't work (though
the behavior has changed).
Comment 3 Michael Brown 2004-11-22 09:30:32 EST
It will never work while the remote site is returning a redirect to:
Location: http://wermi15avip:1110/View?docId=Index&siteId=AC

It should work now - looks like they've fixed their site.
Comment 4 Andre Robatino 2004-11-22 10:58:43 EST
  Thanks for clarifying that it was the Web site that was broken, and
not Firefox - I wasn't sure what constituted a proper host name.  (I
noticed that both Mozilla and Konqueror worked as expected.)  Anyway,
I'll have to send them an email - the URL is still broken for me,
though I found a different one that works.  So this bug should
probably be closed.
Comment 5 Christopher Aillon 2004-12-03 23:44:55 EST
Agreed.  Thanks for the analysis.

Note You need to log in before you can comment on or make changes to this bug.