User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713225625
Steps to reproduce:
I typed an explicit https URL in the address bar.
FF showed the page using http instead. (The page was visited many days before using http, and apparently FF recognizes the typed URL as equivalent to the one in the history, ignoring the all-important https component.)
For example, visit: http://de.wiktionary.org/wiki/Augenbraue
Then type https:// at the start of the address bar en hit Enter.
No go. The https part is discarded.
(Clicking a link works fine, of course: https://de.wiktionary.org/wiki/Augenbraue)
FF should honour the typed URL, consider http and https as fundamentally different, and refetch the requested page using https.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603134204
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603154604
dd6ec482a85d Marco Bonardo — Bug 720081 - Part 1: backportable solution for autocomplete controller to provide a different final defaultComplete value for typeAheadResults r=gavin
It's already reported here https://bugzilla.mozilla.org/show_bug.cgi?id=769994#c5 in scenario #2. And this comment from Marco Bonardo too: https://bugzilla.mozilla.org/show_bug.cgi?id=769994#c8
*** This bug has been marked as a duplicate of bug 769994 ***
Not a dupe - this bug is the opposite of bug 769994, per the summary. IIRC, preferring https is intentional, and we should never override that with "http".
Marco can you look into backing out bug 720081 in that case so we don't ship 15 with this regression?
We can't back out the patch, it's critical to the functionality of inline autocomplete. The "regression" shipped in 14, and doesn't seem to be affecting all cases, so if it comes down to it we can ship with this again, but we should definitely make an effort to investigate and correct it.
I tried the steps in comment 0, but I cannot reproduce, it goes to the https version for me. Can anyone else confirm steps?
(In reply to Marco Bonardo [:mak] from comment #7)
> I tried the steps in comment 0, but I cannot reproduce, it goes to the https
> version for me. Can anyone else confirm steps?
I think it's the same scenario as this bug.
At this point in FF15 cycle we must wontfix for 15 but please keep this as a priority for 16.
*** Bug 784248 has been marked as a duplicate of this bug. ***
When prefixing https in address bar or changing https to http, I still remain at the same protocol that I used before.
* Enter http://commons.wikimedia.org/wiki/Special:Contributions/Republicoat with C&Past in address bar
* Press enter key. "http://" disappears.
* Wait until page is loaded
* Clicking before the first char in the address bar in order to prepend "https://". Enter "https://" using the keyboard.
* Clicking enter
* Firefox, again loads the page, but *not using HTTPS*, but instead *HTTP*
* Add or modify a query-parameter so the URL is a different one
* Allow me switching to HTTPS
(In reply to Rainer Rillke from comment #11)
> * Clicking before the first char in the address bar in order to prepend
> "https://". Enter "https://" using the keyboard.
> * Clicking enter
hm this is strange cause inline ac is active only when the mouse cursor is at the end :(
Btw, looking into this.
so, looks like there is a missing condition for typeAhead results in the controller, the suggested string should always contain the input value.
The problem comes from the fact you search for
"https://something", the code strips the prefix and searches for "something", it finds "http://something" and suggests it, at this point we lack the check.
So this could either be fixed:
- in the controller, this would be sort of a firewall for broken searches
- in the search, makes sense that a search can do whatever on the input string but should not suggest nonsense results
Or just in both places, I'd probably do the latter but put an aborting assert in the controller...
Created attachment 663058 [details] [diff] [review]
Blair, if you're too busy please let me know, since this is tracked and I'm late already :)
FF15 was affected, so given where we are in the cycle, we're going to leave this unfixed. Please nominate for FF17 Aurora approval when ready.
*** Bug 792969 has been marked as a duplicate of this bug. ***
Comment on attachment 663058 [details] [diff] [review]
Review of attachment 663058 [details] [diff] [review]:
Seems reasonable :)
@@ +1521,5 @@
> // Add the result.
> + // If the untrimmed value doesn't preserve the user's input just
> + // ignore it and complete to the found url.
> + let untrimmedURL = prefix + url;
Nit: trailing whitespace.
thank you, I had fixed the trailing spaces locally already.
Comment on attachment 663058 [details] [diff] [review]
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 720081
User impact if declined: we are not respecting what the user types, so he may end up to the unwanted page
Testing completed (on m-c, etc.): m-c, automated test
Risk to taking this patch (and alternatives if risky): regressions in autoFill, but it's quite well covered by tests, and the change is quite contained
String or UUID changes made by this patch: none
ARGH! This just cost me half a day try to figure out whether I had done something wrong in my new ASP.NET MVC application. Broken in v15 indeed, very very inconvenient! Sorry, I just had to complain.
*** Bug 801247 has been marked as a duplicate of this bug. ***
*** Bug 806143 has been marked as a duplicate of this bug. ***
*** Bug 806323 has been marked as a duplicate of this bug. ***
*** Bug 807292 has been marked as a duplicate of this bug. ***
Verified as fixed on Firefox 17 beta 6 - 20121113065533.
I wasn't redirected to http for any pages in the above comments, nor other web pages.
Verified as fixed in FF 17.