1362766 - URL fixup should not redirect localhost:8000 to http://www.localhost.com:8000/

Status: RESOLVED DUPLICATE of bug 1087380

(Core :: DOM: Navigation, defect)

Description

[Ed Morley [:emorley]]

STR:
1) Be developing a site locally, but have forgotten to start the webserver running on port 8000
2) Type `http://localhost:8000/` or just `localhost:8000` in the address bar.
3) Press enter

Expected:
Timeout shown, but URL in address bar remains as that entered, so that after correctly starting the webserver, I can press refresh on the timeout page and view the development site.

Actual:
Timeout shown, but the URL has been redirected/updated to `http://www.localhost.com:8000/`, such that after starting the webserver I have to re-type `localhost:8000` and can't just press refresh.

I hit this pretty frequently when developing.

Toggling `browser.fixup.alternate.enabled` to `false` prevents the fixup from interfering.

Note that the behaviour is correct when connecting to `localhost` with no port specified - presumably since the domain matches the default whitelist entry of `browser.fixup.domainwhitelist.localhost`.

As such, I think there are a few issues (all but the first should likely be handled later):
1) The hostname should have port removed prior to performing the whitelist pref lookup
2) Perhaps hostnames that include ports should be exempted from fixup entirely?
3) Reading browser.js's gKeywordURIFixup() plus bug 1088050 comment 1, there is mention of a notification that prompts about whitelist addition. However I don't see such a notification - presumably due to the timeout? Ideally I would still see the notification even in this case, so I could add a new whitelist entry.

The code in question appears to be here:
https://dxr.mozilla.org/mozilla-central/source/docshell/base/nsDefaultURIFixup.cpp#795-1000
https://dxr.mozilla.org/mozilla-central/rev/37a5b7f6f101df2eb292b1b6baaf1540c9920e20/browser/base/content/browser.js#836-960

Comment 1

[:Gijs (he/him)]

(In reply to Ed Morley [:emorley] from comment #0)
> Toggling `browser.fixup.alternate.enabled` to `false` prevents the fixup
> from interfering.
> 
> Note that the behaviour is correct when connecting to `localhost` with no
> port specified - presumably since the domain matches the default whitelist
> entry of `browser.fixup.domainwhitelist.localhost`.

I don't think that's the case - the alternative (ie what would happen without the whitelist) would be to do a search, not redirect to www.foo.com (ie do alternate fixup) for the input 'foo', so it's not clear to me why you think the behaviour is related to the whitelist.

> As such, I think there are a few issues (all but the first should likely be
> handled later):
> 1) The hostname should have port removed prior to performing the whitelist
> pref lookup
> 2) Perhaps hostnames that include ports should be exempted from fixup
> entirely?
> 3) Reading browser.js's gKeywordURIFixup() plus bug 1088050 comment 1, there
> is mention of a notification that prompts about whitelist addition. However
> I don't see such a notification - presumably due to the timeout? Ideally I
> would still see the notification even in this case, so I could add a new
> whitelist entry.

This is a straight-up dupe. As bug 1087380, the original bug, notes, this behaviour goes back to well before 693808 landed, so I don't think it's related at all. This also explains (3), and means (1) doesn't make sense as that's not the problem here. (2) is basically what I suggested in bug 1087380 comment #2. It would probably mean changing this code: http://searchfox.org/mozilla-central/source/docshell/base/nsDefaultURIFixup.cpp#526 to check for a port on the URI it's being passed.