Steps to reproduce: 0. Clear history & bookmarks 1. Visit http://en.wikipedia.org/wiki/ABC and https://en.wikipedia.org/ 2. Enter 'en.wikipedia.org/' in the location bar and hit enter Actual results: Goes to http://en.wikipedia.org/ Expected results: Goes to https://en.wikipedia.org/ Since http://en.wikipedia.org/ did not exist in the history, and the HTTPS version *did*, it should go to the latter. A couple more examples: * Bug (expected HTTPS): - Visit http://en.wikipedia.org/wiki/ABC and https://en.wikipedia.org/wiki/ - 'en.wikipedia.org/wiki/' goes to HTTP * Works: - Visit http://en.wikipedia.org/wiki/ABC and https://en.wikipedia.org/wiki/123 - 'en.wikipedia.org/wiki/123' goes to HTTPS - 'en.wikipedia.org/wiki/' goes to HTTP (cannot assume HTTPS) - 'en.wikipedia.org/' goes to HTTP (cannot assume HTTPS) Note that for reasons outlined in bug 769994, we cannot blindly prefer the HTTPS version. Tanvi's 'Proposal 1' [1] would make for a more thorough solution, but that requires adding an error flag to pages in the history. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=769994#c125

Clarification of step 2: 2. Enter 'en' in the location bar and let it autocomplete into 'en.wikipedia.org/' (with '.wikipedia.org/' highlighted as a selection). Now hit enter. Reply to Marco (https://bugzilla.mozilla.org/show_bug.cgi?id=902338#c3): > ...but we don't autocompete if you also type the trailing "/". Note that I didn't type the trailing "/" - it was autocompleted for me. But still: if I go to 'en.wikipedia.org/' and I have visited 'https://en.wikipedia.org/', but never 'http://en.wikipedia.org/' - surely it should choose HTTPS? > [...] Basically anything over simple queries will be too much slow. Is an extra/different query required to see that I have never visited the HTTP version while I *have* visited the HTTPS version of the URL in the location bar?

(In reply to Dan Wolff from comment #1) > Note that I didn't type the trailing "/" - it was autocompleted for me. But > still: if I go to 'en.wikipedia.org/' and I have visited > 'https://en.wikipedia.org/', but never 'http://en.wikipedia.org/' - surely > it should choose HTTPS? only if the https page had been manually typed, autofill considers only typed urls. > > [...] Basically anything over simple queries will be too much slow. > Is an extra/different query required to see that I have never visited the > HTTP version while I *have* visited the HTTPS version of the URL in the > location bar? it's a bit more complicated, yes. Cause you have to ensure both that https exists but nothing else exists.

(In reply to Marco Bonardo [:mak] from comment #2) > it's a bit more complicated, yes. Cause you have to ensure both that https > exists but nothing else exists. But that already happens for completely typed URLs... it'd be nice if "en.[wikipedia.org]" (part of it selected with autofill) did the same as if nothing in the URL was selected...

A lot of web servers today offer secure access and Firefox' autocompletion should not prefer the unsecure one. Sadly, this seems to be the current implementation as indicated in the last paragraph in comment #0 (Description). There, you mention that this behaviour "for reasons outlined in bug 769994" can not be implemented "blindly". That bug 769994 has attracted quite a lot of comments and I admit that I've only read the top comments. It's my impression that bug 769994 is more about overzealous autocompletion sending a fully qualified and entered http-URL to the https version. Anyway, times have changed. I believe autocomplete ("visit" entry, first suggestion) should always prefer the secure version of the same domain by design.

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #4) > Anyway, times have changed. You may be true, but we need trustable data about that, we can't make a call just cause we think it *may* work. It would require a specific measurement. Regardless, bug 1239708 may help, since we'd stop caring about "typed" and start dynamically following the user's browsing behavior. The point of bug 769994 is that whatever behavior we take, we break the other one.

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.