Closed Bug 246788 Opened 20 years ago Closed 19 years ago

Errors in handling domain fixup and gobrowsing values

Categories

(Firefox :: Address Bar, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED EXPIRED

People

(Reporter: jgc_nospam, Assigned: bugs)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.8

Firefox doesn't handle several combinations of the properties
browser.goBrowsing.enabled and browser.fixup.alternate.*

If both gobrowsing and fixup are disabled, FireFox still uses Google to do an I
feel lucky-search and redirect to the first page found.

If gobrowsing is disabled and fixup is enabled with no changes to prefix and
suffix, the fixup part did work o.k. at times - but not right now.

At other times I have tried to have gobrowsing disabled, fixup enabled and a
user set value for suffix - this would be my prefered setting, but it doesn't
work at all. The browser just asks Google for a page (as if gobrowsing was
enabled) and never tries to fix the address using the prefix and suffix values.


Reproducible: Always
Steps to Reproduce:
1. Set browser.goBrowsing.enabled to false (use about:config)
2. Set browser.fixup.alternate.enabled to true (default value)
3. Set browser.fixup.alternate.suffix to .dk (or another user set value)
4. Type gyros in the location bar
5. Press enter

Actual Results:  
The browser does a Google search and enters www.gyros.com (check the status bar
- it is not just the fixup that changes gyros to www.gyros.com)

Expected Results:  
Visited www.gyros.dk (due to the fixup settings). 

If fixup is also disabled, the browser should just alert the user that the
address http://gyros could not be found.

I think the major problem is the handling of the browser.goBrowsing.enabled
property (just a guess - could it be a difference between small and capitol b in
"goBrowsing" that causes problems?). I am not sure that the
browser.fixup.alternate.* properties are involced - but as I have written, it
seemed to me that the fixup function worked if gobrowsing was disabled and the
prefix and suffix of fixup was unchanged. 

PS: I'm using 0.9 of Firefox. The build identifier seems to claim 0.8, but it is
the final 0.9 version I am using. The problem was the same in 0.8 and FireBird 0.7.
I can verify that browser.fixup does not work.  If I set browser.fixup to false
and type a single name into the address bar it still adds "www" and ".com" to my
request when it should not.  

This is a problem for people on corporate intranets which use simple server
names as addresses...  ie. http://localserver/page.htm is a perfectly valid url
on my intranet, but firefox wants to make it
http://www.localserver.com/page.htm, which may be valid but I don't want to go
there... 
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.