Closed Bug 769994 Opened 12 years ago Closed 11 years ago

Inline autocomplete selects HTTPS domain against HTTP domain by default

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Version:
14 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 24
Tracking Flags:
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 + verified

People

(Reporter: oscarguit, Assigned: mak)

References

Details

(Keywords: regression, Whiteboard: fixed by bug 769348)

Attachments

(1 file)

Screenshot demonstrating that we already have enough information to know that http://nytimes.com is better than https://nytimes.com in my profile
26.06 KB, image/png
Details 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20100101 Firefox/14.0
Build ID: 20120628060610

Steps to reproduce:

Try enter www.ua.es with Firefox 14 beta.


Actual results:

it goes by default to https://www.ua.es which is not indeed to navigate but to webdav, so it ask for a password and you cannot see the website if not writing http:// by hand.


Expected results:

open http://www.ua.es
URL: www.ua.es
I tried with FF13, FF14 and FF16, Firefox doesn't add https:// to www.ua.es on Win 7.

Can you try in safe mode (http://kb.mozillazine.org/Firefox_Safe_Mode) and if that doesn't work, with a new test profile (https://support.mozilla.org/en-US/kb/Managing-profiles).
Thank you for your reply. I tried with a new profile and FF14 doesn't add https, but it seems to depends on the browser history. I was able to reproduce the problem using a new profile with these steps:

1. Open with a new profile. Type www.ua.es. It goes to http
2. In a new window or tab, type https://www.ua.es and it will ask you for a password.
3. In a new tab, type www.ua.es. From now it will go by default to https.

It seems to be that if you entered to any folder or subdomain using https, it will use https for the whole site...
Confirmed against Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120630030532.

If you paste the "www.ua.es" String instead of typing, it works.
Component: Untriaged → Bookmarks & History
OS: Mac OS X → All
QA Contact: untriaged → bookmarks
Version: 14 Branch → Trunk
Ugh, even if I explicitly type http://www.ua.es the Awesomebar decides to load the https Link - all happening within a single Tab. This Behavior seems broken (even if indented per Code).
I think it's the "new" behavior of inline autocomplete after bug 720081 landed in FF14.

But I see 2 scenarios of your example.

NB: all the tests must be done with a new profile.

-- Scenario #1:

1. Type www.ua.es and press enter.
2. Open a 2nd tab and close the 1st tab.
3. Type https://www.ua.es/ (with / at the end) and press enter.
4. Open a 2nd tab and close the 1st tab.
5. Type www.ua.es and press enter.

Result: 
After step #5, Firefox sends the user to https://www.ua.es/ (displayed https://www.ua.es in the location bar).
That's bad because, each time the user types www.ua.es, Firefox sends him to the HTTPS domain. If the user adds / at end of www.ua.es he can reach the HTTP domain again.

-- Scenario #2:

1. Type www.ua.es and press enter.
2. Open a 2nd tab and close the 1st tab.
3. Type https://www.ua.es (without / at the end) and press enter.

Result:
After step #3, Firefox sends the user to http://www.ua.es/ (displayed www.ua.es in the location bar).
That's bad because the user can't reach the HTTPS domain https://www.ua.es/ without adding the / at the end. Of course, if the user adds / at the end of https://www.ua.es he falls into the scenario #1 again.


What I understand about scenario #1:
After your typed www.ua.es in step #5, Firefox autocompletes to www.ua.es/ according to bug 720081 (www.ua.es is already in location bar history).
When you press enter, Firefox loads https://www.ua.es/ because it's the only instance of www.ua.es with / at the end.

So I think there is a regression in scenario #1.
Blocks: 720081
Status: UNCONFIRMED → NEW
Component: Bookmarks & History → Location Bar
Ever confirmed: true
Keywords: regression
QA Contact: bookmarks → location.bar
Hardware: x86 → All
Version: Trunk → 14 Branch
Thank you.
I can reproduce both scenarios.
By the way, in Scenario #1, step 5, if you delete the / (it was added by autocompletion) or if you write www.ua.es[space] you go to http.
Summary: https by default? → Inline autocomplete selects HTTPS domain against HTTP domain by default
I'm not sure there's anything we can do here, autocomplete will always prefer the secure version of the same domain by design. I can't think of a way to distinguish edge cases where the non secure version may be preferred.
Though it's possible to use the result from the popup rather than the filled suggestion.
Though scenario 2 looks wrong, it should go to the secure version.
Would it not be possible to keep the secure protcol by preference, on the condition that the page being autofilled exists, in secure form, in the history?

As far as I can tell, the autocomplete can deduce the existence of the page "example.com" by visiting "example.com/folder", which makes sense. However, presuming that "https://example.com" is a valid link because an https:// entry exists elsewhere on the site, isn't as sensible, especially where sites that once had secure pages, but no more, are concerned.

Short of deleting every entry for that site in the history, at least being able to just delete the offending entry would make it work, while not compromising the secure-by-default design.
(In reply to Death from comment #11)
> However,
> presuming that "https://example.com" is a valid link because an https://
> entry exists elsewhere on the site, isn't as sensible, especially where
> sites that once had secure pages, but no more, are concerned.

It sounds hard to do this properly, performance-wise, it's hard to do it manually already. Most of the issues seem to come from poorly (maybe just because used for local testing) managed web servers so far.
I think something could be done changing the datastore format, but has to be verified, also would break the by-design request to autocomplete to the domain first.

> Short of deleting every entry for that site in the history, at least being
> able to just delete the offending entry would make it work, while not
> compromising the secure-by-default design.

fwiw you can group history by site in the sidebar and delete the site in one click
What's "buggy"  is that it uses "https" also when the user never typed a https link.
If you go to a page with "http" default, then log into that page and get forwarded to a https page, next time the auto completition will use "https" as default which can't be in the users interest. Since the user never typed in a https adress, it should use the http adress, since that's usually the public interface for such sites.
Continuing from Neumi's point, I think it's also worth noting that visiting a website with HTTP will either work as normal, or redirect to HTTPS, whilst visiting a website with HTTPS will either work similarly to normal, or do something 'unintended', such as request a password or simply fail.

The users intentions should also be taken into account - if they aren't typing HTTPS before the site, it's highly likely they don't expect to be taken to the HTTPS page. Pretty much any website that is designed to be read in HTTPS will automatically redirect any unsecure traffic to the secure protocol appropriately.

Websites are designed to interpret the clients actions without making any presumptions, so visiting a HTTP page wouldn't make a difference as it would handle it properly. I don't think therefore it's a good idea to have the browser make a change that would alter what the user would percieve without them requesting it specifically, in this case, putting https:// before their URL.
I recently encountered this for my company's website at www.WorldMusic.org.  We use a secure portion of our site, but the main public site is under http.  Having visited my company's site and having it in my browser history, the URL was auto completing to the https:// index page when i would type in our url (without the prefix).  This initially, until I discovered the problem) took visitors to a server generated message saying that we had not put in a proper index page or the site was under construction.  Many of our site visitors are returning customers and I'm sure many use Firefox as a default browser.  I simple fix was, since we don't utilize the index.html page in the secure portion of the site, was to create a redirect.  But I still feel that this behavior is not intended and limits our ability to utilize the secure site separately from that of the unsecured site.
This is a huge problem for us.  Our website www.rrm.com uses https://www.rrm.com/forum so any of our vistors who have used our forum are experiencing issues when they return to http://www.rrm.com and have it flip to https:/www.rrm.com.  Or maybe I should say we are having issues because all of the rest of our website stops serving ads (using openx on our server) because of the https.  You have taken the webmaster's control over how the webpages are accessed and now we cannot specify http where it is needed.  Not only that but using https where not needed is a waste of server resources and against best practices.
My solution on the server side.

Put following in the .htaccess file on your server:

RewriteEngine On 
RewriteCond %{HTTPS} on 
RewriteRule ^$ http://www.yourdomainname.com/ [R=301,L]
Appreciate the tip but I'm on IIS7 and, the only place I want https is on URLs like this:  https://www.rrm.com/forum  -- I don't want it anyplace else.  Only Firefox has taken this control from webmaster and users -- all the other browsers respond to webmaster and user typed URLs as directed by the webmaster and user.
>> all the other browsers respond to webmaster and user typed URLs as directed by the webmaster and user.

Actually, some of my colleagues reported the same behaviour for Safari on OS X yesterday too. But this is not the right bugtracker to discuss about. :)

Nevertheless, i fully agree with you. Firefox should not take control from the users.
This was very confusing for me, as an HTTPS Everywhere user.  I had to set browser.urlbar.autoFill -> false to access some URLs on sites that have since turned off HTTPS (e.g. blip.tv).
We're experiencing this issue as well, and it's causing confusion for individuals using our content management system.  Our site lives at:

    http://domain.com

but the editing interface lives behind authentication at:

    https://domain.com

Even when explicitly typing the http:// URL and not using autocomplete, it redirects the browser to the logged in view.  The opposite seems to happen as well, possibly depending on which version (http:// or https://) was most recently accessed.

We first started noticing this issue with Firefox 14, which had updates to make searches https by default, and I wondered if that might be part of it.
This is a bit of a show stopper for me... I use a lot of local development urls. For instance I might have a live site www.mysite.com (and has an ssl) but I use dev.mysite.com to access my local dev site. When I go to my dev sites FF tries to go to the secure version and it doesn't exist. Frankly it's a pain!
I am writing as a web site manager, not a contributor to the project.  I agree with comments 21 and 22.  There are definitely valid use cases for web sites running under http and https as noted in comment 23 and this puts the onus on web site developers to put a patch in place to account for behavior unique to a single browser.  I could be wrong, but I think that port 80 remains the default for most web traffic and our applications should act accordingly.  A logical autocomplete behavior, to me, would go like this:

In cases where both http and https urls are in the browser history, autocomplete to http and let then let web site managers forward to https if desired

In cases where the only url in the history is https, then by all means autocomplete should honor that.

My two cents
big fat pain.
I purchase from play.com - that uses https when processing the purchase - but the main site to browse products is http. If I just type play in the awesomebar it now takes me to an error page . I have to manually delete the s in https to access the site. Not good.
+1 to be fixed.
This has decreased the traffic to my site because firefox proposed https which does not exist because it's behind free cloudflare account.

It also does not let me login at my site.
So just for this I switched to chrome.

It's a pity that it is not fixed in firefox 14, 15 and I m wondering how much time it will take till my visitors will install a fixed version of firefox.
Till then I will suffer traffic loss.

Please fix it asap.
Thanks a lot
I also reproduced it with bookmark. If at least one domain has been bookmarked with https, all the request for a http url will be automatically redirected to a https url.

Only webmaster should decide which page or subdomain have to be redirected to https. It's not the role of a web browser to define the security rules of each other but it's the role of a webmaster or security admin.

Other big collateral damage is that websites hosted in shared server, share the same ssl certificat that suppose to ask the first time an authorisation page before entering in the homepage. This is not acceptable and can be very problematical business web site.

Please fix it to give firefox the free way it should be run. This bug should have been mark in "critical" status.
I've encountered a case where https://www.example.com/ returns a 403 response (http://www.example.com/ returns a 200), but Firefox still prefers the HTTPS address when I type only 'www.example.com'. I think it would be better if 403s (and certain other status codes) caused FF not to consider the HTTPS address to be valid, and therefore not prefer it.
We may avoid setting the page as typed if it's an error page, that could even make sense, but should be a separate bug to evalute, so please file it apart?
My thought is that if someone *explicitly* puts http://example.com or https://example.com in the URL, the browser should honor that request as typed.

If they *don't* specify the protocol, then I can see the rationale behind applying this logic to automatically select the protocol.  However, I consider the current behavior broken, since it's giving the user something different than they requested.

As an aside to anyone else experiencing this bug, the workaround we found is that if you want to go to the URL you actually typed in, add a space after the URL and it will take you to the correct URL.

I have noticed that it's gotten a little better as of Firefox 15.0.1 (although I've just gotten in the habit of using the space bar trick so I may not be seeing it as much.)
"f they *don't* specify the protocol, then I can see the rationale behind applying this logic to automatically select the protocol. "

I Don't agree with above statement -- what happens when the website owner no longer needs the SSL and so no longer offers https?  The viewer then gets an error page and cannot access the website via http and because there is no longer https offered, Firefox prevents the viewer from seeing the regular http pages

and, try telling your website visitors to type a space after the website address -- not going to happen -- this is an unrealistic expectation
Marco Bonardo wrote: 

> We may avoid setting the page as typed if it's an error page, that could even 
> make sense, but should be a separate bug to evalute, so please file it apart?

I have filed this behaviour as Bug 792856.
(In reply to debra from comment #35)
> I Don't agree with above statement -- what happens when the website owner no
> longer needs the SSL and so no longer offers https?  The viewer then gets an
> error page and cannot access the website via http and because there is no
> longer https offered, Firefox prevents the viewer from seeing the regular
> http pages

This argument is invalid. It is the same as "What happens when the web site changes its domain name?"

Any well-managed web server needs to continue running for the forseeable future on all relevant ports and protocols.

(It is also unlikely that the server admins will wish to discontinue SSL; much more likely they might wish to discontinue port 80 non-SSL service. But still, the answer is the same: continue running on port 80 with a redirect.)
This scenario happened to me.  Whether you consider me a well-managed server admin is debatable but what isn't is that Firefox forcing https is a new behavior and removes control from both the viewer and the webmaster.

We enabled SSL for vBulletin Facebook connect.  However, the latest Firefox https preference forced users to access other non-vBulletin pages using https.  This meant, anybody who had visited the forum under https was then forced to use https when visiting a non-ssl page like domain.com or other pages which didn't require SSL.  

This caused our OpenX ads to stop serving -- ie, they would not appear on pages accessed via https only displayed when via http.  OpenX has very little support these days and we could not figure out how to get the ads to display via http and since vBulletin's Facebook Connect wasn't being used by very many of our forum participants, we discontinued it and removed ssl.  

Then, users were getting error message because Firefox was forcing https access. So, we renabled SSL and set up a redirect from https to http.

All of this because Firefox forces https.
I'm changing the behavior in bug 781617 so that if the user types a certain scheme it will be preserved, as it should be.  That's not the final answer to this bug, more work is needed, but should at least allow the user to state what he wants.
(In reply to John Hawkinson from comment #37)
> (In reply to debra from comment #35)
> > I Don't agree with above statement -- what happens when the website owner no
> > longer needs the SSL and so no longer offers https?  The viewer then gets an
> > error page and cannot access the website via http and because there is no
> > longer https offered, Firefox prevents the viewer from seeing the regular
> > http pages
> 
> This argument is invalid. It is the same as "What happens when the web site
> changes its domain name?"
> 
> Any well-managed web server needs to continue running for the forseeable
> future on all relevant ports and protocols.
> 
> (It is also unlikely that the server admins will wish to discontinue SSL;
> much more likely they might wish to discontinue port 80 non-SSL service. But
> still, the answer is the same: continue running on port 80 with a redirect.)

This argument is not invalid.  Many websites choose to discontinue services that required a SSL to begin with and if their visitiors are forced to go to the HTTPS protocol when a cert no longer exists, they'll hit an error.  Redirecting to the proper protocol should be left solely up to the administrator of the website.

If a Firefox user decides that they want to configure their browser to automatically attempt pulling up the HTTPS protocol in favor of the HTTP, they should make that choice.

The only way the browser should make the decision for the user is if it can first determine if a valid cert exists on the HTTPS protocol.  If it did that, I don't think this whole discussion would be taking place.

My current situation is even more strange that what I've read.  When working in a test environment, I have the secure protocol pulling up an entirely different resource than non-secure.  I don't remember ever going to that address, but it goes there anyway (eg: typing test.example.com in the AwesomeBar goes to https://test.example.com/secure_file.html instead of http://test.example.com/).  I've removed "https://test.example.com/secure_file.html" from my history and AwesomeBar history, but it continues to behave as previously stated.  I love Firefox, but this behavior is becoming intolerable!
please keep the bug report clear as far as possible, the reasoning and issues are quite clear at this point.
(In reply to Loic from comment #5)
> -- Scenario #2:
> 
> 1. Type www.ua.es and press enter.
> 2. Open a 2nd tab and close the 1st tab.
> 3. Type https://www.ua.es (without / at the end) and press enter.
> 
> Result:
> After step #3, Firefox sends the user to http://www.ua.es/ (displayed
> www.ua.es in the location bar).
> That's bad because the user can't reach the HTTPS domain https://www.ua.es/
> without adding the / at the end. Of course, if the user adds / at the end of
> https://www.ua.es he falls into the scenario #1 again.

(In reply to Marco Bonardo [:mak] from comment #8)
> Though scenario 2 looks wrong, it should go to the secure version.

For the record, this is covered by bug 781617.
> (In reply to Marco Bonardo [:mak] from comment #8)
> > Though scenario 2 looks wrong, it should go to the secure version.
> 
> For the record, this is covered by bug 781617.

Yep
+1. seperated our secure server to a subdomain, big harm, forced buying an SSL just for redirection.
In my case, I was trying to go to a regular http://www.foo.com URL and it kept redirecting to https://www.foo.com which didn't exist and thus produced an error message.

It turned out that about 6 MONTHS ago I had tried to go to that website and had accidentally typed "https" instead of "http." This was buried deep in the Firefox History. I deleted that item from the History and the redirect stopped. Problem solved.

Still, it should go to whatever you type into the navigation bar, no matter what was in the History.
(In reply to RonM from comment #51)
> Still, it should go to whatever you type into the navigation bar, no matter
> what was in the History.

Did you type http:// explicitly?
(In reply to Marco Bonardo [:mak] from comment #52)
> Did you type http:// explicitly?

Explicitly specifying the protocol does not help with this bug, an existing https history entry will override it.
(In reply to Nicos Gollan from comment #53)
> Explicitly specifying the protocol does not help with this bug, an existing
> https history entry will override it.

This bug has been fixed in Firefox 17
Hey Marco, I wanted to clarify with you that per your comment 39, the fix in Firefox 17 is only a partial fix.  I just tested in 17 and typing an explicit protocol does take you to that location.  However, typing just a hostname still defaults to the https version if an https history entry exists.  Is there a plan to address that portion of the bug?
Marco, I agree with Brandon above... I would not consider this fixed, as long as I type domain.com and I'm being redirected to https://domain.com, just because at some point I was on some secure page from that domain. This is the case with most online stores, where only a few checkout/account pages should be secure.
(In reply to fstroe from comment #56)

I should refine: Even if you visited the SAME address on the secure server before, it's still a bad idea to force autocomplete to the secure version. The site owner will need to keep the SSL forever, even if they don't need it anymore, or moved the secure system to a different subdomain, different server etc. And visitors will have trouble with external files / banners where it's not intended.
First of all - Comments #56 and #57 are RIGHT ON. This is a major problem and you have largely screwed a ton of web developers until this is not only fixed, but the the versions that contain this feature are phased out of existence.

Do we even need to keep going over why this "feature" was a horrible idea?

This is so messed up you should somehow NUKE all versions in the wild that has this feature via a silent patch update channel or something.

Your little "feature" is causing tons of traffic to be lost.

Im totally beside my self that you guys would just throw this **** in there and screw us all like this.

TAKE IT OUT NOW!

Oh and the messed up part about all of this, is that there is nothing I can do for some of these sites via mod rewrite because the cert errors get thrown long before mod rewrite ever starts. Nothing I can do except buy additional and unneeded SSL certificates so that the site works "the way firefox wants it to".

Did you guys just buy a cert signing company? Trying to make some money?
You want to fix this bug? Here is the answer, the only answer and anything less is unacceptable: 

NEVER, EVER, EVER ADD HTTPS TO AN AUTO-COMPLETE ENTRY UNLESS:

A - THE USER ACTUALLY TYPES IN HTTPS://
OR 
B - EVERY SINGLE INSTANCE IN THE HISTORY OF A SITE IS ACCESSED VIA HTTPS AND NO STANDARD HTTP REFERENCES EXIST IN THE HISTORY AT ALL.

Look, I understand you are trying to "save everyone" by "keeping them secure" but you guys really have no idea what kind of pandora's box you opened with this. I mean this is a major problem. MAJOR. And if you dont see that then you aren't looking close enough.
I agree to remove the  feature: the auto complete uses https even if I www.xxx.com
It's really user unfriendly.

Just give users the option what to type into the bar themselves. HTTP or HTTPS.
The user must know what he/she does, if they don't I suggest they ask any good computer users how to use the browser. Besides, when you click any login button, they usually forward you to the HTTPS page already.

The problem I face is: I don't log off the secured login page, it times out, because I put my laptop to hibernate etc. The next time it forces me to open the HTTPS page. But cannot open. I type many other addresses and it keeps going to HTTPS... that's truly frustrating!

My solution was: remove history, cookies ,etc
But now I log off, that removes my session info....

But still, this feature is bad!!!! (see the 4 exclamation marks?

Just remove please, it's the users responsibility.....
(makes me think about M$, forcing people to love windows 8... sign....
I'll go even further.  If this "feature" ( I use the term advisedly ) does not go away soon, I will DUMP FIREFOX ENTIRELY.  Luckily, there are plenty of web browsers out there, and I have my choice for my own webtools.  And my staff will use whatever browser I tell them to.
(In reply to Jerry Kaidor from comment #61)
> I'll go even further.  If this "feature" ( I use the term advisedly ) does
> not go away soon, I will DUMP FIREFOX ENTIRELY.  Luckily, there are plenty
> of web browsers out there, and I have my choice for my own webtools.  And my
> staff will use whatever browser I tell them to.

Hello. It would be good you read the Buzilla etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) before posting pointless comments as on a dicussion forum. Use mozilla.dev.apps.firefox if you want to start a constructive thread instead of using BMO which is a dev tool about tracking bugs.
Um, I was just commenting on the importance of this bug.  Every development environment makes decisions about what's important and what's not.  Because engineers do not have infinite time.  This is IMHO a very important one.
@Jerry, still the post was completely pointless and rude. The developers are well aware of the importance. Flaming does not help at all. This is not a place to complain, but a place to find a solution.

@topic:

It looks like ther have been a slight change.
I have pages of both "http://www.gog.com" and "https://www.gog.com" in my browser history.

a)Typing "www.gog.com" in the adress bar forwards correctly to "http://www.gog.com".

b) Typing "gog.com" in the adress bar still forwards incorrectly to "https://www.gog.com" and ends with a error message.

(Tested with Firefox 17)
well, it looks like I have to take back my previous report.
a) worked only two times so far, I can't reproduce it on a regular base. I don't know what triggered it to work as it should.
(In reply to Brandon Sterne (:bsterne) from comment #55)
> Hey Marco, I wanted to clarify with you that per your comment 39, the fix in
> Firefox 17 is only a partial fix.

In comment 54 I replied to a specific issue, saying "this bug is fixed", the "this" part was related to what I quoted, not to THIS bug. As you can see the bug is still open.
(In reply to Neumi from comment #64)
> @Jerry, still the post was completely pointless and rude. 

*** OK, it was.  I apologize.  I was just really frustrated at the time, and I guess I suspected that it wasn't really a bug, but rather a policy decision.  And that if it was a policy decision and not a bug, I would have to give up Firefox, because it would no longer work for many websites - including my own server!  That would be a shame, because Firefox is a fine browser.  I especially enjoy all the development plugins.

   It didn't even seem totally unlikely or off the wall that it was a policy decision, because Ff is used by the general public - and Net safety is a big deal.  I can imagine a group of programmers sitting around in a Silicon Valley meeting room ( with bagels and coffee on the side table ) talking about how the world should be encouraged to go total https, how that would hamstring both net scammers and Big Brother, and how Ff can lead the revolution :).

   Again, I apologize to the Firefox development team for my post, and wish I could just delete it.  The Russians have a saying "Slovo ne vorobei, vyletit ne poimesh", which means "A word isn't a nightengale.  Once it flies out, you'll never catch it back".
            - Jerry Kaidor
This has been an issue since 14, here's someone's post: http://support.mozilla.org/en-US/questions/933470

Please do something about this issue.
I just tested this on the beta version of Friefox (18r3) and the behavior still exists as in previous versions. I was hopeful the behavior would be rolled back in version 18.
(In reply to Reid G from comment #69)
> I just tested this on the beta version of Friefox (18r3) and the behavior
> still exists as in previous versions. I was hopeful the behavior would be
> rolled back in version 18.

Aw man, seriously? We're starting to receive more emails that our pages aren't loading correctly. Here's a comment from an external source:

"In FF, this redirected to https://www.example.com/, (no bookmarks or autocomplete) whereas in Chrome/IE it goes to www.example.com (no http or https). Wondering if FF is looking at something like a 301 redirection (or similar). Very bizarre."

Come on FF Dev DO something!
This broken and confusing behavior is still happening. 

If I go to the trouble to type 

   http://www.something.url 

It's because that's where I want to go.
It's one thing to try and interpret a user's typing of some keywords, that I can understand. 
But we are talking about deliberately typed in fully qualified URLs being arbitrarily changed by the browser.

There is no world in which this is sane or reasonable behavior for a publicly trusted browser. 

Arbitrarily changing one URL into another is ALWAYS wrong. Period.
(In reply to Jerry Kaidor from comment #67)
> (In reply to Neumi from comment #64)
> > @Jerry, still the post was completely pointless and rude. 

Rude? Maybe.

Completely pointless? Absolutely not.

If a problem with the browser causes users to consider switching to a different browser, stating that fact is absolutely a legitimate and valid point to make.
(In reply to bmercer from comment #71)
> If I go to the trouble to type 
> 
>    http://www.something.url 
> 
> It's because that's where I want to go.

That's indeed what happens from Firefox 17 on, unless you meant you typed that without specifying the scheme, so just "www.something.url".

That said, there's no point commenting in an OPEN bug saying the bug still exists, that's why the bug is open.
Having the same issue here. For websites it's not a too big issue (for me), since I have a preference. However, I often setup networks. I once had a router on 192.168.1.1 that worked on https, but normally all is through http. But now, I'm always redirected to https by Firefox. Highly annoying.

Thanks for a quick fix (I already solved it temporarily by disabling autofill/autocomplete).
What is wrong with you Firefox people? If I have a website that I enter 100 times a day by typing it or selecting in address bar and I make a mistake ONCE to enter it using https protocol then Firefox suddenly uses https every single time. Do you know how completely infuriating it is?
I'd like to say that I don't wanna be rude, but unfortunately I do. It's really hard for me to understand how completely blind can you be to NOT FIX IT IN HALF A YEAR?!
It's a game breaking issue. It makes me want to stop using Firefox, not because it's not a good browser, it's not fast, or full of features I like. Cause it is. No. Just because of this one idiotic issue.
And there are many reasons one may end up with https entry in their history:
- server issue with a website, that redirected to https; fixed after 5 minutes... you were the unfortunate one
- someone sends you an email or pastes you an URL with https added. For whatever reason. For example, cause they know you're using Firefox and they hate you.
- you type https by yourself, cause you feel like being stupid. Or you misunderstood someones instructions.
- the site used to use https now it doesn't
- ...

The funny thing is that it's not only a major annoyance to some unfortunate people browsing the web but also, from what I read above, a very real problem for some websites, decreasing their traffic. And who knows what impact does it have globally... ARE YOU SERIOUSLY IGNORING THIS?!

Ffs, fix it already!
I totally agree with guy above. I am a web developer so sometimes I have to go to https versions of a site for admin related things but still need to go to http for the public site. It's really annoying that the auto complete doesn't at least show you the protocol so you know where you're going. The workaround I have found is to start typing the domain name I want then when it shows up in the url bar hit right arrow to move cursor to end of auto populated name then hit backspace to erase the trailing slash at the end of the domain name. Then hit enter. This will go to http version. Otherwise it goes to https version if I don't erase the trailing slash.
(In reply to Carl von Buelow from comment #78)
> The workaround I have found is to start typing the domain name...

you can even just type the protocol in front of the domain, or select a result from the dropdown autocomplete.
(In reply to Marco Bonardo [:mak] from comment #79)
> (In reply to Carl von Buelow from comment #78)
> > The workaround I have found is to start typing the domain name...
> 
> you can even just type the protocol in front of the domain, or select a
> result from the dropdown autocomplete.

Of course, that makes sense to someone who understands what a protocol is and someone who understands that this bug exists.  To a standard user, they would just be confused and assume a website that used to have a cert and no longer does, is broken.

I work with a large list of clients, some who have SSLs and decide to eliminate the annual cost after re-evaluating whether the cost of having one is worth whatever feature they're using it for.  Once their cert is gone, any user whose browser auto-completes to the https protocol will either assume the site they're trying to access is down/broken or insecure.

I don't want to start a flame war here, but you really have to view the issue from a standard user's point of view.  Looking at it any differently isn't fair to the end user or any website owner that has made changes to how they handle requests to their http(s) protocols.

Also, I've resorted to circumventing this problem by typing a space after the address I'm trying to go to.  It works for me, but then again, it took me about a month to figure that out.
Is there not yet enough evidence and angst here to get someone to work on this? Please, Firefox?!
I'd like to add my frustration and opinion as defaulting to port 443 is just not right.   It even does it when an SSL cert is not installed, resulting in an error page.  It's just wrong.  Please fix it, it can't be hard.
Depends on: 840027
While I understand the rationale behind this behaviour I feel it would work better if it paid closer attention to the sub folder.

e.g. if I have visited https://www.website.com/secure/ in the past I would like autocomplete to default to https when I type "website.com/secure" but not when I type just "website.com" to visit the root.
Not sure if the below belongs to this particular bug, but the problem also happens with other protocols.  I frequently access gcc.gnu.org as HTTP and as FTP site.  Having http:// version as a bookmark, as soon as I typed ftp://gcc.gnu.org, the FTP version became the autocomplete target so I cannot get to the HTTP site.  Even if I delete the FTP site from the autocomplete suggestions, still I get to the FTP site when typing 'gcc' and autocompleting this to gcc.gnu.org.  Even if I type http://gcc.gnu.org manually, this doesn't change the autocomplete default protocol and still redirects the 'gcc.gnu.org' autocomplete to the FTP version.
(In reply to Andrey Belevantsev from comment #85)
> Not sure if the below belongs to this particular bug, but the problem also
> happens with other protocols.  I frequently access gcc.gnu.org as HTTP and
> as FTP site.  Having http:// version as a bookmark, as soon as I typed
> ftp://gcc.gnu.org, the FTP version became the autocomplete target so I
> cannot get to the HTTP site.

that's bug 769348, the resolution there could be simpler since it doesn't involve security issues.
This also breaks the loading of ***many*** homepages and content sections that are not designed to run in HTTPS and thus include resources and tags from other domains in plain HTTP (including cdn) but have a checkout or user profile section in HTTPS and then end being suggested as HTTPS: sites' layout and behavior is being broken because if this bug: "normal" isn't the right level of attention for this bug.

This is even more critical since bug 62178 and others about mixed content are being handled.
I am starting to run into this more and more and it's causing me major annoyance. I can't imagine what trouble it must be causing for regular users who aren't too computer-savvy and assume that a website isn't secure.

I think that comment #59 had a great solution: only doing this if a user added the https explicitly or if every single entry in the history was on https.
I manually fixed this issue by going to my history and deleting all the https entries.
I just wanted to add my 2 cents to this bug.  I work on a website that is in the range of 100 million page views per month, and is served via http.  However, we log thousands of attempts to access our site via https everyday. We put some serious investigation into why this was happening, and the vast majority of that was traced to this bug.

We found that this issue spiked when Google started serving their page through https as part of their Google Plus rollout.  We saw that many people who have Google set as their home page, and are logged in, simply open their browser, and type the url of the website they want to go to right over "google.com" - leaving the https in place.   Once they do that one time, it's all over - Firefox remembers that and will always direct them to the https version of that site - even if there isn't one.

The Internet is full of solutions that individuals should take to fix this problem (like delete the https version of the site from your history), or that webmasters can take (like add an apache redirect from https to http), but shouldn't a software setting that causes problems with thousands of users be addressed at the source - in this case in Firefox?  When we first saw this issue, it affected such a significant portion of our users that we thought that this would be a burning issue with Firefox and that it would be fixed right away. However, we've been seeing this problem for a year now, and I noticed this bug is over a year old and still not assigned or fixed. Maybe it's just me, but I feel like this is a bigger problem for Firefox that folks seem to recognize, and it's not getting any attention.
@Rusty, you are spot on.

How has this not been fixed yet? It cannot be difficult to fix that? What more evidence do you need to assign someone to fix this problem?

I have really been avoiding switching to chrome because I've always used Firefox; however, its looking more and more like I will need to be, and recommending everyone I know to be, switching to chrome.
Everyone who is commenting, PLEASE VOTE for this bug to be fixed.  Comments are great, but votes are much better. 
I work in support at a major research university and we are making preparations to drop Firefox as a preferred/supported browser because of this problem.  We have many servers running SSL for secondary pages, but not for primary browsing. 

I have put in my vote for this to be fixed.  Have you?
(In reply to Tracy S from comment #93)
> Everyone who is commenting, PLEASE VOTE for this bug to be fixed.
>.... 
> I have put in my vote for this to be fixed.  Have you?

I certainly haven't...how/where do you do that?
(In reply to Steve from comment #94)
> (In reply to Tracy S from comment #93)
> > Everyone who is commenting, PLEASE VOTE for this bug to be fixed.
> >.... 
> > I have put in my vote for this to be fixed.  Have you?
> 
> I certainly haven't...how/where do you do that?

Right at the top / header section on the bug page (this page).  Look for the line that starts with: 

Importance: 	-- normal with 50 votes including you (vote) 

The "50 votes" is actually a link that you can click to cast your vote to vote for this bug.
done, thanks!
(In reply to Tracy S from comment #93)
> Everyone who is commenting, PLEASE VOTE for this bug to be fixed.  Comments
> are great, but votes are much better. 
> I work in support at a major research university and we are making
> preparations to drop Firefox as a preferred/supported browser because of
> this problem.  We have many servers running SSL for secondary pages, but not
> for primary browsing. 
> 
> I have put in my vote for this to be fixed.  Have you?

I have
Voted. This behavior is broken and bogus (brogus?) and it's shameful that it hasn't been fixed. Tweeting this, feel free to copy and tweet:

Have a Mozilla bugzilla account? Please vote for bug 769994 to be prioritized: http://bit.ly/OULG7d Redirecting to https is broken & bogus
Good idea!

Voted and retweeted @tom_swiss:

    https://twitter.com/tom_swiss/status/319466604352122880
(In reply to mkennetgillman from comment #100)
> Please see a related discussion here:
> http://www.reddit.com/r/webdev/comments/1byofz/
> firefox_23_will_block_nonssl_content_on_ssl_pages/

this discussion is confusing mixed content with inline completion, doesn't make any sense in this context.
The reason it makes sense in this context is that it is breaking many pages.  You use autocomplete and it takes you to the ssl page, but then it blocks all non-ssl content on that page.
Marco, note that this bug gets worse with mixed-content blocking, because it causes more https urls to work poorly.  For example, a month ago, accidentally getting https://nytimes.com wasn't so bad, but now it's broken because of 862164.
yes, that makes sense.
Marking "tracking-firefox23?" per comment 104.  (Bug 834836 landed for Firefox 23.)
URL: www.ua.es
tracking-firefox23: --- → ?
I'm a mere user but I'd like to chime in here. As many have mentioned before, this "feature" is indeed a bug and it is highly annoying. 

I'm using hotel wireless hotspots with captive portals a lot. My firefox default home page is set to a site that also has an https protected area. However the default URL is explicitly stated as http://www.url.tld. Firefox still overrides this to SSL causing the captive portal to not work. Every single time I need to edit the URL to what is stated in the configuration dialog (http instead of https as protocol) to allow login to the captive portal. 

It's perfectly fine and a good feature if Firefox tries SSL by default if the entered URL is ambiguous (no protocol stated). However full URLs including the protocol if typed in directly in the address bar, stored in configuration dialogs or selected from auto-complete should never be changed to SSL if http was explicitlely stated by the user. 

I really hope this gets fixed soon. 

Thanks!
(In reply to Richard Stevens from comment #107)
> It's perfectly fine and a good feature if Firefox tries SSL by default if
> the entered URL is ambiguous (no protocol stated). However full URLs
> including the protocol if typed in directly in the address bar, stored in
> configuration dialogs or selected from auto-complete should never be changed
> to SSL if http was explicitlely stated by the user. 

No, it's not fine in either way. For the reasonings, read the full thread. Shortly, the site may not need / use HTTPS anymore, or HTTPS address may be used for another section (backend) of the site. Even, another site on the IP may have began using HTTPS, so a totally different site may open on HTTPS.

It's like blasting airbags into the faces of the people in a car in advance, during normal journey, just in case they may crash somewhere.
Bottom line is, the browser is deliberately overriding the user's intention, and that's bad. 

If the safety concern is really what this is about, at least provide a configurable option to turn this undesirable behavior off.
Richard, can you file a new bug report on your home page issue, and give the bug number here?  That probably has a different cause (and requires a different fix) from this location bar bug.
(In reply to bmercer from comment #109)
> If the safety concern is really what this is about, at least provide a
> configurable option to turn this undesirable behavior off.

Configuration option is good for experienced users, but doesn't solve this.

An average user who types the site url without the protocol will still think the site is broken, if the site drops the usage of SSL or moves the secure server to a different subdomain.
(In reply to Marco Bonardo [:mak] from comment #12)
> manually already. Most of the issues seem to come from poorly (maybe just
> because used for local testing) managed web servers so far.

At a minimum, When the user types nytimes.com into the address bar and hits enter, and he has never visited https://nytimes.com/ before, then the nytimes.com home page must load correctly. Ideally if any part of the HTTPS version of the site works then all parts would work, but that just isn't reality. Whether that's poor design on the website's part is debatable, I guess. But, regardless, we need to load http://nytimes.com correctly when the user types in nytimes.com into the awesomebar and right now, in Firefox 23 Aurora, we fail at that. I would love this to be something I could legitimately blame on the mixed content blocker, but really the behavior that this bug describes is just clearly unworkable as the internet exists today and I would be very surprised if it isn't hurting many sites that aren't affected by the mixed content blocker at all--especially considering the many comments and duplicate bug reports seen over the last nine months on this bug.

Gavin, is there somebody that can fix this and uplift the fix to Aurora?

If it is too difficult to fix this in general for Firefox 23, then we should implement a hack that overrides any autocomplete that would result in https://www.nytimes.com to instead become http://www.nytimes.com.
status-firefox21: --- → affected
status-firefox22: unaffected → affected
Flags: needinfo?(gavin.sharp)
(In reply to Brian Smith (:bsmith) from comment #112)
> Gavin, is there somebody that can fix this and uplift the fix to Aurora?

How do you propose fixing it without regressing bug 720081? Or are you suggesting we regress bug 720081?
Flags: needinfo?(gavin.sharp)
Please keep in mind that I am trying to answer your question in an earnest attempt to be as helpful as I can be, but I am about as far from being an awesomebar expert. Also, I realize that it is annoying to have people say "this is clearly wrong" when they don't have great solutions; however, sometimes people can recognize an obvious problem while still not knowing how to solve it. This is one of those times. With that out of the way...

For starters, when deciding between http://nytimes.com/ and https://nytimes.com, we could just choose the higher-ranking result. See the screen shot I am attaching: it shows that the awesomebar already ranks http://nytimes.com/ higher than https://nytimes.com in my profile and it is extremely confusing for it to choose a lower-ranking option over a higher-ranking one.

I would also suggest that perhaps we should separate the notion of autocomplete into two categories: domain autocomplete and URL autocomplete. Domain autocomplete is when we try to help the user finish just the domain name that they are typing in; it might result you going to a page that you've never been before. URL autocomplete is where we try to help you navigate to a specific page that you've been to before; you will never end up at a page that you've never been to before with URL autocomplete.

Now, I suggest that we try something like this (assume the user typed in "exa" and we know that they have been to at least one page on example.org, either the HTTP or the HTTPS variant, or perhaps an alternate port, or a combination of all of that).

1. Try domain autocomplete. If that works, resolve that to all scheme/host/port combinations that the user has visited; that is, take all the URLs in the history for that hostname, strip off all the paths except the first "/", and de-dup: e.g. visited_hosts = { http://example.org/, http://example.org, https://example.org/, http://example.org:1234/ ).

2. Search the places database for all the URLs in visited_hosts, and save all the exact matches in normal awesomebar rank order. Example: If the user successfully navigated to the URLs https://example.org/ and http://example.org:1234/, and they more often navigate to http://example.org:1234/, then visited_homepages = [ http://example.org:1234/, https://example.org ]

3. If visited-homepages is not empty then auto-complete to visited-homepages[0]. (After the user presses enter, then if navigation fails--the connection fails, we get a 404 response, etc.--we should demote and eventually remove that URL after a small number of failures; awesomebar probably already does this.

4. Otherwise, if visited_hosts is not empty, auto-complete the domain part only (ignore scheme and port) and navigate as if the user had entered that exact text without the help of autocomplete. For example, imagine that the user cleared their history, typed "example.org" into the address bar, and pressed enter; we would try http://example.org and then (I think) http://www.example.org. Then, we should do the same in this case.

5. Otherwise, if visited_hosts is empty, then autocomplete doesn't do anything.

I would also say that, regardless of the my browser history, if I type in a complete hostname and press enter, then Firefox should navigate to that exact hostname; no www vs. no-www fixing unless/until we've at least attempted to navigate to the exact hostname that was entered.
Also: In general we are conditioning users that the lack of an explicit scheme means "http://". So, IMO, if inline autocomplete really thinks the HTTPS variant is the best choice (for whatever reason), then it should add the https:// prefix. And/or, at least it should provide some indication that it will make a choice that defies the "no scheme means http://" convention.
(In reply to Brian Smith (:bsmith) from comment #114)
> 1. Try domain autocomplete. If that works, resolve that to all
> scheme/host/port combinations that the user has visited; that is, take all
> the URLs in the history for that hostname, strip off all the paths except
> the first "/", and de-dup: e.g. visited_hosts = { http://example.org/,
> http://example.org, https://example.org/, http://example.org:1234/ ).

Sorry, I meant visited_hosts = { http://example.org/, https://example.org/, http://example.org:1234/ ).
Brian, please see also bug 840027.

The problem is that we don't know if the domain should be visited in https or http in many cases, so we need a fallback, the fallback currently is "check if any https visit to that domain exists". As we know from this bug it's not perfect, on the other side the "use https only if all known pages use https" is again not perfect, since it may expose to using http more, when we should have used https.
So there is a plausible security issue where we wrongly send the user to http, while there is a a plausible usability issue when we send him to a nonexisting https. bug 840027 suggests a possible solution involving the UI, where the user must explicitly accept to go to the unsafe version. That is not yet perfect, but at least should avoid safety issues.

Additionally to this, there is a performance problem, since this happens while the user is writing, we must keep querying at a minimum, so we can't pay the price for multiple queries to the db just to figure what's better, we need very good caching strategies to come up with the best result immediately.

On the other side, the www. and ftp:// issues should be solved by bug 769348, for those there is no safety issue so we can just fallback to "use www. or ftp:// if all known pages contain them", that should satisfy most cases.
If we think we can rely on servers to enforce secure redirects for their users (not sure based on what we could make that assumption though) then we could use the same strategy for https for now.
It seems to me that this is turning into a case of over-engineering. 

At some point the user needs to take some personal responsibility for ensuring that they are using a secure connection. The more software tries to "help" people do things right, the less likely they are to develop the right habits to protect themselves.
(In reply to Marco Bonardo [:mak] from comment #117)
> The problem is that we don't know if the domain should be visited in https
> or http in many cases, so we need a fallback, the fallback currently is
> "check if any https visit to that domain exists". As we know from this bug
> it's not perfect, on the other side the "use https only if all known pages
> use https" is again not perfect, since it may expose to using http more,
> when we should have used https.

I understand that and I agree. And, definitely I want to get the user using HTTPS as much as possible.

However, consider the case where the user has *never* visited the domain before. We default to http://. Every HTTPS-only site has to account for that fact, redirecting users to the https:// variant. In the future, we should do more to make that more secure, however I consider that to be a future problem to solve. However, keep in mind that for a site to properly address the security concern you mention, the site needs to implement HSTS and that if the site implements HSTS then we'll automatically rewrite (in Necko) the http:// request to the https:// variant.

My argument is that, unless we are very confident that something more clever is better, then we should do the thing that is most likely to work, and the thing that is most likely to work seems to be the "act like the user never visited the site" behavior.

> bug 840027 suggests a possible solution involving the UI,
> where the user must explicitly accept to go to the unsafe version. That is
> not yet perfect, but at least should avoid safety issues.

If I type nytimes.com into the awesomebar, Firefox shouldn't ask me *every time* whether I want to go to the unsafe version. My position is that, when I type nytimes.com into the awesomebar, I must always get the normal nytimes.com home page without prompting, just like any other browser. So, I don't think that bug 840027 is a plausible solution for nytimes.com. (BTW, I will also verify in the security team meeting that we are reaching out to nytimes.com to make them aware of this issue so that they can fix it on their end with a redirect.)

Now, maybe nytimes.com is exceptional in how it works (though, from the history of this bug, it doesn't seem to be too exceptional). And, generally I want us to go to the secure version of a site by default whenever that works. Getting this working (even/especially for sites the user has not been to previously) is already on the radar of the security team. Unfortunately, I think it is a problem that we can't solve right away. And, also unfortunately, the mixed content blocker feature is likely to increase the number of sites that are negatively affected by this bug. (This is why there is a sudden increase in interest of this bug; we don't want the mixed content blocker to get backed out of the release because it increases the impact of this bug.)

> Additionally to this, there is a performance problem, since this happens
> while the user is writing, we must keep querying at a minimum, so we can't
> pay the price for multiple queries to the db just to figure what's better,
> we need very good caching strategies to come up with the best result
> immediately.

I understand that this is a major consideration.

> On the other side, the www. and ftp:// issues should be solved by bug
> 769348, for those there is no safety issue so we can just fallback to "use
> www. or ftp:// if all known pages contain them", that should satisfy most
> cases.

www vs. no-www I am not too sure about. I don't have the data to know how many sites are negatively affected by us doing the simple thing and relying the site to redirect one to the other as appropriate.

But, for ftp://, since FTP is so uncommon, I would say that we should *never* automatically do domain autocompletion to a ftp:// URL. IMO, consistent behavior between the "never visited the site before" vs "have visited the site before" behavior is more important, from a usability standpoint, than making it easy to get to the root of an FTP server that you've visited before.

> If we think we can rely on servers to enforce secure redirects for their
> users (not sure based on what we could make that assumption though) then we
> could use the same strategy for https for now.

I am not sure what you mean here by "enforce secure redirects" here. If you mean "redirect http://X to https://X" then that will always be somewhat insecure, unless/until the site uses HSTS, because an attacker could just replace the redirect with his own response. However, I suggest that we consider solutions to this kind of problem to be future work that doesn't need to be solved right now.
Marko, it's good intentions, but the result is sadly not quite good.

The very simple solution, IMHO: a config setting.  Let the user decide.
Why not have a flag "default to http or https"?
(In reply to Brian Smith (:bsmith) from comment #119)
> However, consider the case where the user has *never* visited the domain
> before. We default to http://. Every HTTPS-only site has to account for that
> fact, redirecting users to the https:// variant.

This is a good point, that may allow us to just fallback to the "any known page" case. What's still unfortunate is we could be able to anticipate that and increase safety, though we don't have enough data for that now.

> > bug 840027 suggests a possible solution involving the UI,
> If I type nytimes.com into the awesomebar, Firefox shouldn't ask me *every
> time* whether I want to go to the unsafe version.

The idea there was not to ask everytime, just to ask once, I figure that's not very good yet, since the certificate may change, may be dropped and so on.

> generally I want us to go to the secure version of a site by default whenever that works

Yep, unfortunately it's not an info we have when building autocomplete data, we don't even know if the previous visit was successful.

> www vs. no-www I am not too sure about. I don't have the data to know how
> many sites are negatively affected by us doing the simple thing and relying
> the site to redirect one to the other as appropriate.

There are quite a bit, indeed one of the reasons to implement the behavior was websites handling www-only, while users typing non-www, for various reasons, included the fact autocomplete always trimmed away www in searches, so they are used to skip it.

> But, for ftp://, since FTP is so uncommon, I would say that we should
> *never* automatically do domain autocompletion to a ftp:// URL.

I think the fallbak will still be good enough for this, if ftp.something.com is always served through ftp it's very likely it doesn't even have http. The user can still manually type http:// and from that point on ftp won't be suggested anymore.

So, I think the plan of action for now could be to just modify bug 769348 to cover all the prefixes, that should solve most of the issues, the security concern is mitigated by the fact pages must be ready to handle http case, as you well expressed. In future we may figure better solution to increase safety of this (maybe by having a flag indicating whether previous load of the https version ended up succesfully).

(In reply to Steve from comment #120)
> Marko, it's good intentions, but the result is sadly not quite good.
> 
> The very simple solution, IMHO: a config setting.  Let the user decide.
> Why not have a flag "default to http or https"?

I never denied the current solution is bad. That said, the kind of option you suggest is not something we should give to nontechnical users, and the issue here is exactly with those users, others are well able to bypass this behavior already.
Tanvi - we're specifically tracking this because it is greatly increased with mixed content blocking enabled.  Are you able to find someone to assign to this or should we need-info? Gavin?
Flags: needinfo?(tanvi)
as I said, it's just matter of completing (and slightly modifying) the patch in bug 769348, if this is a priority I can finish it, please just define its importance with Gavin.
Depends on: 769348
(In reply to Marco Bonardo [:mak] from comment #121)
> So, I think the plan of action for now could be to just modify bug 769348 to
> cover all the prefixes, that should solve most of the issues, the security
> concern is mitigated by the fact pages must be ready to handle http case, as
> you well expressed. In future we may figure better solution to increase
> safety of this (maybe by having a flag indicating whether previous load of
> the https version ended up succesfully).

That sounds great to me.

> I never denied the current solution is bad. That said, the kind of option
> you suggest is not something we should give to nontechnical users, and the
> issue here is exactly with those users, others are well able to bypass this
> behavior already.

I agree. Such an option is pretty counter-productive, because power users (the kind that tend to report bugs and participate in Firefox development) may elect to use the option and then forget about the issue.
I think we should try to land a solution in FF 24 and uplift to FF 23.

The patch in bug 769348 does the following:
 *  - if any page starts with https://www. return https://www.
 *  - if any page starts with https:// return https://
 *  - if all of the typed pages start with ftp: return ftp://
 *  - if all of the typed pages start with www. return www.
 *  - otherwise don't use any prefix 

In the "otherwise don't use any prefix", we default to http://, correct?

Comment 117 and comment 121 indicate that the awesomebar cannot determine if any of the https:// pages returned a 404 or with an certificate error.  If in the future, we find a way to solve the performance issues and we can add some sort of an "error" flag, I think the following would be a good solution.
Proposal 1:
 *  - if any page starts with https://www. && that page is not marked with the error flag, return https://www. If that page is parked with the error flag, check the next https://www. match and continue until there are no https://www. matches left.
 *  - if any page starts with https:// && that page is not marked with the error flag, return https://. If that page is parked with the error flag, check the next https://www. match and continue until there are no https://www. matches left.
 *  - if all of the typed pages start with ftp: return ftp://
 *  - if all of the typed pages start with www. return www.
 *  - otherwise don't use any prefix  (and hence default to http://)

Since we are not at a place where Proposal 1 is possible, I think we should go with the following behavior (that Marco mentioned in comment 121) to fix the usability issues we are currently having.

Proposal 2:
 *  - if all pages start with https://www. return https://www.
 *  - if all pages start with https:// return https://
 *  - if all of the typed pages start with ftp: return ftp://
 *  - if all of the typed pages start with www. return www.
 *  - otherwise don't use any prefix (and hence default to http://)
Flags: needinfo?(tanvi)
that is correct, thanks for the sum up.
Assigning this to Tanvi in that case so we have someone accountable for finishing up the steps here and getting notifications of tracked bug reminders.
Assignee: nobody → tanvi
I believe Marco is going to write the patch for this in bug 769348.  Marco, do you want to take this bug too?
sure.
Assignee: tanvi → mak77
The behavior changed in Bug 769348 so that https will only be suggested if all of the typed pages contain it. If the prefix is still suggested cause it was previously typed, it should now be enough to type once the unprefixed version to have the urlbar cope with that (where typed also means just edit once the suggested page to the non-https one).
Since the behavioral change, any issues with that should be filed in a new bug.

marking as fixed by Bug 769348.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: fixed by bug 769348
Can we uplift to aurora?  Should I put the uplift request in this bug or in bug 769348?
ideally we could, though uplifiting without running the Nightly train (at least for a week) makes me nervous in this case, cause the patch involves database version bump and that's not undoable.
(In reply to Marco Bonardo [:mak] from comment #132)
> ideally we could, though uplifiting without running the Nightly train (at
> least for a week) makes me nervous in this case, cause the patch involves
> database version bump and that's not undoable.

Okay, lets see if we can uplift next week.  I will make the uplift request in bug 769348, since that is where the patch is.  And then we can wait to actually land on aurora until early next week.
This was fixed over in bug 769348 so can we mark it fixed here now too?
Flags: needinfo?(mak77)
status-firefox23: affected → fixed
Flags: needinfo?(mak77)
Target Milestone: --- → Firefox 24
Keywords: verifyme
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20130723 Firefox/25.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20130723 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20130723 Firefox/25.0

Verified as fixed on Firefox 23 beta 8 (Build ID: 20130722172257) and Nightly 25.0a1 (Build ID: 20130723030205) by using STR from comment 5.
Status: RESOLVED → VERIFIED
status-firefox23: fixed → verified
Keywords: verifyme
This bug is *not* fixed in FF 28.

I've been trying to load http://userscripts.org:8080/ or any other page there but FF 28 insists on changing the HTTP to HTTPS even though I explicitly type the HTTP part.

The https version returns an error.  Effectively, FF prevents me from visiting the sties I want to use.
IE9 has no problem.
(In reply to Alex from comment #136)
> This bug is *not* fixed in FF 28.
> 
> I've been trying to load http://userscripts.org:8080/ or any other page
> there but FF 28 insists on changing the HTTP to HTTPS even though I
> explicitly type the HTTP part.

This is very strange, the code doesn't overwrite what you type, so if you explicitly typed http, it won't go to https unless there's a redirect or force SSL server side.
My mistake, figured out it was scriptish forcing userscripts.org to https
the bug is not fixed, it got worse in v30.
i don't mind any autocompletion scheme,

but please respect the exact explicit url entered.
i have a site that supports either http and https.
but my development site has an explicit port and http only, on the same host.

now, i cannot access any page on the development, that doesn't support https at all.
even explicit redirects to http pages get rewritten to https.

best regards,
alex
(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #135)
> 

sorry, the bug is not fixed,
it got worse in v30. i am using debian iceweasel 30.
i don't mind any autocompletion scheme, 
but please respect the exact explicit url entered. 
i have a site that supports either http and https. 
but my development site has an explicit port and http only, 
on the same host. 
now, i cannot access any page on the development, 
that doesn't support https at all. 
even explicit redirects to http pages get rewritten to https. 
best regards, 
alex
just type https or the port when you need them. if it doesn't work please check your add-ons and prefs.
(In reply to Marco Bonardo [:mak] from comment #141)
> just type https or the port when you need them. if it doesn't work please
> check your add-ons and prefs.

thanks marco for your consideration.

it happens in safe mode, with autofill* and/or autocomplete disabled, 
with or without the typed filkter in the history, 
and even if the url is the result of a server redirect.

i simply cannot use ff anymore.

let me try anything you wish,
alex
It's very strange that it may happen with autoFill disabled, nothing should ever interpret what you type in such a case.
please file a separate bug and put very detailed steps we can use to reproduce your bug 1:1, so we can discuss that case better.
(In reply to Marco Bonardo [:mak] from comment #143)
> It's very strange that it may happen with autoFill disabled, nothing should
> ever interpret what you type in such a case.
> please file a separate bug and put very detailed steps we can use to
> reproduce your bug 1:1, so we can discuss that case better.

are you sure it doesn't happen to you?
my site is http[s]?://misradia.co.il(:8080)?
it happens on android too.
Hi Alex,

your HTTPS server is setting the "Strict-Transport-Security" header and that is preventing both Firefox and Chrome to access the HTTP version after you've visited the HTTPS version once.

See: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
(In reply to Francesco Negri from comment #146)
> Hi Alex,
> 
> your HTTPS server is setting the "Strict-Transport-Security" header and that
> is preventing both Firefox and Chrome to access the HTTP version after
> you've visited the HTTPS version once.
> 
> See: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

thank you very much francesco.
from your link i found out the hsts list is been preloaded in the browser.
now that i disabled hsts on the server, how could i edit the preloaded list?
(In reply to alex bodnaru from comment #147)
> now that i disabled hsts on the server, how could i edit the preloaded list?

Clearing the cache should be enough. :) (Or try right click and "forget about this site" from the history)
This bug still exists, as of FF v32.0 + setting these has no effect.

browser.urlbar.autoFill -> false
browser.urlbar.autocomplete.enabled -> false

This is very ugly.

Someone let me know how to turn off this nonsense.

Thanks.
(In reply to David Favor from comment #149)
> This bug still exists, as of FF v32.0 + setting these has no effect.

Please file a new bug report describing your issue. Thanks.
status-firefox21: affected → wontfix
status-firefox22: affected → wontfix
(In reply to David Favor from comment #149)
> This bug still exists, as of FF v32.0 + setting these has no effect.
> 
> browser.urlbar.autoFill -> false
> browser.urlbar.autocomplete.enabled -> false

if the bug is still reproducible with those set, it's not this bug at all, and likely not a firefox bug. Did you check comment 146, for one of the possible reasons it might happen?
Comment #146 doesn't apply in this case.

slnet1# curl -I -L frenchcuffy.com
HTTP/1.1 200 OK
Date: Thu, 04 Sep 2014 14:37:29 GMT
X-Pingback: http://frenchcuffy.com/xmlrpc.php
Link: <http://frenchcuffy.com/>; rel=shortlink
Cache-Control: max-age=7776000
Expires: Wed, 03 Dec 2014 14:37:29 GMT
Content-Type: text/html; charset=UTF-8

Shows there's no Strict-Transport-Security header set.
In fact, there is no round trip traffic for this request at all.

Typing http://foo results in https://foo with zero connection to server.

No apache log entries at all, so this is occurring in FireFox.

I'm guessing there's some way to turn this off via about:config + I've tried all manners of settings.

No joy. I'm using FireFox-32 + all updates.
that's fine. But if you set the prefs in comment 149 and can still reproduce, it's definitely not this bug and unlikely an autocomplete bug at all since you completely disabled it...

You should file it apart and try to figure what could make that case special, any details might be useful there.
David et al, please see https://bugzilla.mozilla.org/show_bug.cgi?id=1164262. If this bug describes what you are still seeing then please contribute information to that bug's comments.
I can still reproduce this bug with FF 39.

The server (Apache Tomcat without a https-Connector) doesn't send a HSTS-Header.
please file separately, this bug _cannot be reproduced_ because the code explicitly prohibits the action and tests run everyday ensuring that. If that happens it's surely not due to inline completion (not this bug!).
If it's not due to the auto-completion, what could be the cause instead?

I'm typing http://hostname:port/... and in firefox' network analysis I can only see one GET-Request, which targeting hostname:port over https.
I also have the same problem still, but I think the suggestion is that is isn't an auto-complete problem, but is instead something to so with remembered https for that domain. See https://bugzilla.mozilla.org/show_bug.cgi?id=1164262
Can somebody please briefly summarize why Firefox auto-completion "by design" prefers the HTTP ULR to the secure one? Thanks.

I'm asking here because this bug serves as an "killer" argument not to implement an auto-completion behavior that simply prefers the secure version of the same URL, e.g., see bug #902338 comment 1 or bug #902582 comment 0, last paragraph.

To be frank, I believe location bar auto-complete ("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 #160)
> Can somebody please briefly summarize why Firefox auto-completion "by
> design" prefers the HTTP ULR to the secure one? Thanks.
> 
> I'm asking here because this bug serves as an "killer" argument not to
> implement an auto-completion behavior that simply prefers the secure version
> of the same URL, e.g., see bug #902338 comment 1 or bug #902582 comment 0,
> last paragraph.
> 
> To be frank, I believe location bar auto-complete ("visit" entry, first
> suggestion) should always prefer the secure version of the same domain by
> design.

Because some web servers don't have the same content at https://www.abc.xyz and http://www.abc.xyz . 

If you could guarantee that https://www.abc.xyz/12345/abc.html would always give the same content as https://www.abc.xyz/12345/abc.html, then great. But if the https one 404s and Firefox defaults to it, whooops. (That behaviour was present for a while and it was horrible, hence why it was changed in this bug.)
(In reply to mozilla from comment #161)
> (In reply to Daniel Kabs, reporting bugs since 2002 from comment #160)
> > Can somebody please briefly summarize why Firefox auto-completion "by
> > design" prefers the HTTP ULR to the secure one? Thanks.
> > 
> > I'm asking here because this bug serves as an "killer" argument not to
> > implement an auto-completion behavior that simply prefers the secure version
> > of the same URL, e.g., see bug #902338 comment 1 or bug #902582 comment 0,
> > last paragraph.
> > 
> > To be frank, I believe location bar auto-complete ("visit" entry, first
> > suggestion) should always prefer the secure version of the same domain by
> > design.
> 
> Because some web servers don't have the same content at https://www.abc.xyz
> and http://www.abc.xyz . 
> 
> If you could guarantee that https://www.abc.xyz/12345/abc.html would always
> give the same content as https://www.abc.xyz/12345/abc.html, then great. But
> if the https one 404s and Firefox defaults to it, whooops. (That behaviour
> was present for a while and it was horrible, hence why it was changed in
> this bug.)

Oops, I made a typo. The second https in the above should be http, i.e. If you could guarantee that https://www.abc.xyz/12345/abc.html would always give the same content as http://www.abc.xyz/12345/abc.html, then great. But if the https one 404s and Firefox defaults to it, whooops. (That behaviour was present for a while and it was horrible, hence why it was changed in this bug.)
Yes, the content can differ. Also if you as the website owner decide to remove the SSL from a domain, then your visitors will simply see an error page, thinking the website is down. During the move of our operations it gave us a horrible time as it was not possible to give the domain its own IP and SSL certificate. Even though fx is the browser of my choice, we finally had to advise our visitors to use a different browser, as it wasn't accepted as a bug.
If the user types in some partial URL or just a word, the browser can try to figure out what the user meant. Personally I hate this ****, but I recognize it's what people demand so I can live with it. But if the browser takes a fully qualified URL which is exactly correct and arbitrarily inserts new stuff in the middle of it, that's broken. 

If I type http://www.example.com  and the browser inserts a letter s in the middle, that's just as broken as if it randomly inserts the word BORK in the middle. 

If you own a web site and you want to make sure people go to the secure version, redirect them yourself. Don't try to make other people's browsers do it so you don't have to.
(In reply to bmercer from comment #164)
> If the user types in some partial URL or just a word, the browser can try to
> figure out what the user meant. Personally I hate this ****, but I recognize
> it's what people demand so I can live with it.

Still it breaks it for the user!
VERY few users will know that they need to type the exact full url and AVOID using autocomplete for the site to work. They'll just choose "whatamazingsite.com/members/johndoe/profile?action=view" rather than completely typing it or the bare domain name.


> If you own a web site and you want to make sure people go to the secure
> version, redirect them yourself. Don't try to make other people's browsers
> do it so you don't have to.

I don't think any real webmaster would rely on an autocomplete feature for forcing a secure site.
If your comment was for my previous post, I should clarify. In our case it was something resulting our users get an error page, making them think the site was broken or closed, it wasn't something we relied on =)
Onur, I'm in complete agreement with you, I just didn't express myself well. 

In the past, Firefox would actively change a fully qualified URL that included the protocol and change it from HTTP to HTTPS. That was completely obnoxious. I typed in HTTP://www.mysite.com/content and Firefox actively changed it to HTTPS://www.mysite.com/content, which did not exist. It was impossible to visit the page by typing or copying and pasting a URL into the address bar. An explicit and correctly formatted fully qualified URL should never be arbitrarily changed unless the user specifically chooses to allow such changing via addon or whatever. 

The real problem in my opinion is the blurring of the distinction between an internet URL and a search result. Despite the fact that Firefox comes with a dedicated SEARCH box, people insist on searching from the address bar. If you want to search, search with the search box. If you want to enter a URL, enter the URL. If you enter the wrong URL, you deserve to know that you did by being shown an error. 

Having a single place where you can enter multiple different things and get multiple different kinds of results only makes sense when you have control over all of the possible results. For Wolfram Alpha it makes sense. For a browser on a private computer that could be connecting to anything from a LAN to an old security appliance from ten years ago to an insecure public WIFI to a TOR network, it's just dumb.
If you are having similar issues, please file new bugs, providing full details of what you are seeing and your setup, including any relevant changed preferences. Please be prepared to provide more information on request as well.

Commenting on a bug that is long-closed doesn't help. It was closed at a time when it was considered to be fixed, there's multiple things that have changed since then that may or may not have regressed it, or you are finding a different bug.

Please also read the etiquette before submitting, abusive and whining comments are not allowed: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

I'm restricting comments on this bug as it is long-closed and new issues should be handled in new bugs.
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: