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. Actual results: 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) Expected results: FF should honour the typed URL, consider http and https as fundamentally different, and refetch the requested page using https.

Regression window Good: http://hg.mozilla.org/mozilla-central/rev/0e4f8e1a141b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603134204 Bad: http://hg.mozilla.org/mozilla-central/rev/dd6ec482a85d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603154604 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e4f8e1a141b&tochange=dd6ec482a85d Regressed by 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

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? See https://bugzilla.mozilla.org/show_bug.cgi?id=781617#c2 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.

When prefixing https in address bar or changing https to http, I still remain at the same protocol that I used before. Steps: * 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* Workaround: * Add or modify a query-parameter so the URL is a different one Expected behaviour: * 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...

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.

Comment on attachment 663058 [details] [diff] [review] patch v1.0 Review of attachment 663058 [details] [diff] [review]: ----------------------------------------------------------------- Seems reasonable :) ::: toolkit/components/places/nsPlacesAutoComplete.js @@ +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. https://hg.mozilla.org/integration/mozilla-inbound/rev/9efb8c43ee8a

Comment on attachment 663058 [details] [diff] [review] patch v1.0 [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.

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.