URI strings that include a protocol should not be "fixed up" using alternate URI prefixes/suffixes

NEW
Unassigned

Status

()

Core
Document Navigation
a year ago
a year ago

People

(Reporter: Gijs, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox49 affected)

Details

(Whiteboard: btpp-backlog)

STR:

1. Put "http://mozilla" in the URL bar

ER:
"Domain not found

AR:
You get redirected to "www.mozilla.org". This makes sense when you just type in "mozilla", but not when you type in "http://mozilla" meaning you really actually want that hostname.
Do you have time to fix this, Gijs? How urgently do we need it done?
Flags: needinfo?(gijskruitbosch+bugs)
Whiteboard: btpp-followup-2016-05-31
(In reply to Andrew Overholt [:overholt] from comment #1)
> Do you have time to fix this, Gijs?

I don't.

> How urgently do we need it done?

Probably not super urgent given that bug 1273255 got fixed.

I also realized that this is likely to be very difficult to fix. By the time we do alternate URI fixup after the initial domain has not been found, I'm fairly sure we no longer know if the original input string came with or without the protocol. That is fixable, but it's very much not trivial, and at this stage I'm not sure it warrants the effort.

If/when we redo URI fixup as a JS component (bug 1057531), we can split off the alternate URI fixing as something the browser only does for top-level user-initialized loads, and then it'll be a lot more manageable.
Flags: needinfo?(gijskruitbosch+bugs)
Sounds good.
Whiteboard: btpp-followup-2016-05-31 → btpp-backlog
You need to log in before you can comment on or make changes to this bug.