User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100830 Firefox/4.0b5pre It is not possible to go to any SSL page when using an NTML proxy. (this might happen also on ordinary proxy, but I don't have a way to test it). It started happening with 4.0b5pre, in 4.0b3pre (maybe also 4.0b4pre) it was working ok. Reproducible: Always Steps to Reproduce: 1. Enter a working NTML proxy in firefox (maybe the problem is also with normal proxies) 2. Go to http://gmail.com (you should be redirected to https page) 3. Go to any page that uses SSL Actual Results: Result is a blank page. Expected Results: A login page for gmail, or any other page. Data from troubleshooting page: Application Basics Name Firefox Version 4.0b5pre Profile Directory Open Containing Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Extensions Name Version Enabled ID SeoQuake 2.5.10 false {317B5128-0B0B-49b2-B2DB-1E7560E16C74} Web Developer 1.1.8 false {c45c406e-ab73-11d8-be73-000a95be3b12} Page Speed 1.7.1 false {e3f6c2cc-d8db-498c-af6c-499fb211db97} Microsoft .NET Framework Assistant 1.0 false {20a82645-c095-46ed-80e3-08825760534b} FiddlerHook 2.2.8.9 false fiddlerhook@fiddler2.com Java Quick Starter 1.0 true jqs@sun.com Delicious Bookmarks 2.1.102 false {2fa4ed95-0317-4c6a-a74c-5f3e3912c1f9} Adblock Plus 1.2.2 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} Firebug 1.6X.0b1 true firebug@software.joehewitt.com Modified Preferences Name Value accessibility.typeaheadfind.flashBar 0 browser.places.importBookmarksHTML false browser.places.smartBookmarksVersion 2 browser.startup.homepage https://mail.google.com/mail/?zx=15vwjc6ps4cnf&shva=1#inbox|http://www.google.com/reader/view/#overview-page|file:///C:/… browser.startup.homepage_override.buildID 20100830030934 browser.startup.homepage_override.mstone rv:2.0b5pre browser.tabs.warnOnClose false browser.zoom.full false extensions.lastAppVersion 4.0b5pre font.minimum-size.x-western 10 network.cookie.prefsMigrated true network.dnsCacheEntries 128 network.http.pipelining true network.http.pipelining.maxrequests 8 network.http.pipelining.ssl true network.http.proxy.pipelining true places.history.expiration.transient_current_max_pages 95510 places.last_vacuum 1282910874 print.print_printer \\sgkrkss01\PTR_KRK_D6_HP4515 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_bgcolor false print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_bgimages false print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_command print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_downloadfonts false print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_edge_bottom 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_edge_left 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_edge_right 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_edge_top 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_evenpages true print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_footercenter print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_footerleft print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_footerright print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_headercenter print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_headerleft print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_headerright print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_in_color true print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_margin_bottom 0.5 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_margin_left 0.5 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_margin_right 0.5 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_margin_top 0.5 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_oddpages true print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_orientation 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_pagedelay 500 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_paper_data 9 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_paper_height 11.00 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_paper_size_type 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_paper_size_unit 1 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_paper_width 8.50 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_reversed false print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_scaling 1.00 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_shrink_to_fit true print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_to_file false print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_unwriteable_margin_bottom 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_unwriteable_margin_left 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_unwriteable_margin_right 0 print.printer_\\sgkrkss01\PTR_KRK_D6_HP4515.print_unwriteable_margin_top 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_bgcolor false print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_bgimages false print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_command print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_downloadfonts false print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_edge_bottom 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_edge_left 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_edge_right 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_edge_top 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_evenpages true print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_footercenter print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_footerleft print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_footerright print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_headercenter print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_headerleft print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_headerright print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_in_color true print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_margin_bottom 0.5 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_margin_left 0.5 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_margin_right 0.5 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_margin_top 0.5 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_oddpages true print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_orientation 1 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_pagedelay 500 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_paper_data 9 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_paper_height 11.00 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_paper_size_type 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_paper_size_unit 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_paper_width 8.50 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_reversed false print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_scaling 1.00 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_shrink_to_fit true print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_to_file false print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_unwriteable_margin_bottom 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_unwriteable_margin_left 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_unwriteable_margin_right 0 print.printer_\\sgkrkss01\PTR_KRK_D9_HP4730Color.print_unwriteable_margin_top 0 privacy.cpd.cookies false privacy.cpd.downloads false privacy.cpd.formdata false privacy.cpd.history false privacy.cpd.sessions false privacy.sanitize.migrateFx3Prefs true privacy.sanitize.timeSpan 3 security.enable_java true security.warn_viewing_mixed false Graphics Adapter Description ATI Mobility Radeon HD 3650 Vendor ID 1002 Device ID 9591 Adapter RAM Unknown Adapter Drivers ati2dvag Driver Version 8.503.2.1000 Driver Date 6-27-2008 Direct2D Enabled false DirectWrite Enabled false

You can also try to go e.g. to: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox The page doesn't load.

Reporter, are you willing to try to narrow down when this problem appeared using nightly builds?

I'm not the reporter, but I'm having the same issue. This version works: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-24-04-mozilla-central/firefox-4.0b5pre.en-US.win32.installer.exe This version does not: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-25-06-mozilla-central/firefox-4.0b5pre.en-US.win32.installer.exe

jjbott, can you tell me what the build IDs of those builds (the HTTP urls from about:buildconfig) are? Looks similar to bug 592215; I assume you're using an NTLM (not "NTML") proxy?

Pending the exact build ids, a conservative regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-24+00&enddate=2010-08-25+08 Possible culprits: bug 495115

Working: http://hg.mozilla.org/mozilla-central/rev/9a623cc1c5e7 Not working: http://hg.mozilla.org/mozilla-central/rev/4a6ee9e82945 And yeah, NTLM. :)

Exact range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a623cc1c5e7&tochange=4a6ee9e82945 My money's on STS.

If it helps at all, if I try to go the "gmail.com", the last 2 things I see in Wireshark are the following: 1) Sent to the proxy server: CONNECT www.google.com:443 HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100825 Minefield/4.0b5pre Proxy-Connection: keep-alive Host: www.google.com 2) From the proxy server: HTTP/1.1 407 Proxy Authentication Required Proxy-Authenticate: NTLM Proxy-Authenticate: BASIC realm="<deleted>" Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Proxy-Connection: close Set-Cookie: <deleted>; Path=/ Connection: close Content-Length: 947 <HTML><HEAD> <TITLE>Access Denied</TITLE> </HEAD> <BODY> <deleted> </BODY></HTML>

(In reply to comment #0) > > It is not possible to go to any SSL page when using an NTML proxy. (this might > happen also on ordinary proxy, but I don't have a way to test it). Using a regular proxy (squid) works for me.

Based on comment 9 I'd say: - we still send the original request to load the secure page - we receive the response from the proxy that requires authentication - instead of detecting the need for authentication, we abort

(In reply to comment #10) > (In reply to comment #0) > > > > It is not possible to go to any SSL page when using an NTML proxy. (this might > > happen also on ordinary proxy, but I don't have a way to test it). > > Using a regular proxy (squid) works for me. Well, I should try to configure squid so that it requires password based authentication. Trying that now.

(In reply to comment #12) > > Well, I should try to configure squid so that it requires password based > authentication. Trying that now. Works, too. We'd need access to a NTLM proxy to debug further.

jimm had something, iirc.

(In reply to comment #14) > jimm had something, iirc. I have a web server that supports it for testing web connections. Proxies are tougher since they need the authentication infrastructure in place to do the authentication. I'm not sure I can get something like that set up locally.

I will look around though and report what I find!

Kai, can you put a build together with whatever printf stuff you need to diagnose things (using try server) so that one of the people who can see the problem can just run it and post a log here?

Krzysztof, Joe, could you please test the following: - in the browser's URL bar, type: about:config - confirm the warning - in the "Filter" field, enter: false_start - you'll see the preference named security.ssl.enable_false_start - I assume the value is currently "true" - double click the preference, changing it to "false" - restart firefox and try to connect to your server. Does this fix it?

(In reply to comment #17) > Kai, can you put a build together with whatever printf stuff you need to > diagnose things (using try server) so that one of the people who can see the > problem can just run it and post a log here? It seems difficult to predict what could go wrong.

Krzysztof, Joe, please feel free to ignore comment 18, I no longer believe this option is related.

I have steps-to-reproduce (on Linux) that don't require a NTLM server. Let's prepare a profile, go to preferences, configure Firefox to start up with a blank page, and configure advanced networking, set a proxy server to host 127.0.0.1 port 1234. We'll use netcat (nc) to simulate a minimal server that asks for proxy authentication. - open a text editor - copy all of the following text (between the === lines) to the text editor, to make sure you have it available later (you'll need to copy and paste it later) ======================================= HTTP/1.1 407 Proxy Authentication Required Proxy-Authenticate: NTLM Proxy-Authenticate: BASIC realm="1.1.1.1" Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=utf-8 Proxy-Connection: close Connection: close bla ======================================= - open a terminal - type nc -l 1234 - start old firefox, version 3.x - type https://text.com in the url bar, hit enter - note that firefox stalls - switch to the terminal window - note that it will show text starting with CONNECT test.com:443 HTTP/1.1 - copy the text you have prepared - paste the text into the terminal window - if the cursor is immediately after the word "bla", you'll need to hit enter - now switch back to the Firefox window - you'll see that Firefox prompts you for a username and a password The above demonstrates that NTLM proxy auth and prompting works in Firefox 3. Now repeat the above steps with Firefox 4 beta / nightly. Arriving at the end of the steps, you'll not get the prompt. Since there isn't any SSL protocol involved here, the regression must be in changes to the non-SSL networking code. It would be good if someone with better knowledge of the http implementation code could use these STR to debug what's going wrong.

NSPR_LOG_MODULES="nsHttp:5" ./firefox I compared the output after I paste the fake proxy server response. ... nsHttpConnection::OnHeadersAvailable [this=b7686160 trans=a4af23e0 response-head=a4a01080] SSL proxy CONNECT failed! waiting for the server to close the connection. nsHttpTransaction::HandleContent [this=a4af23e0 count=4 read=4 mContentRead=4 mContentLength=-1] nsHttpConnection::OnSocketReadable [this=b7686160] nsHttpChannel::OnStartRequest [this=a4d3ec00 request=b70fbfa0 status=0] nsHttpChannel::ProcessResponse [this=a4d3ec00 httpStatus=407] WARNING: NS_ENSURE_TRUE(mSecurityInfo) failed: file /plaindata/moz/mocent/mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 959 WARNING: NS_ENSURE_TRUE(mSecurityInfo) failed: file /plaindata/moz/mocent/mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 959 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /plaindata/moz/mocent/mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 1019 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /plaindata/moz/mocent/mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 1019 The NS_ENSURE_TRUE(mSecurityInfo) fails in Firefox 4 It's either new code, or this statement works in Firefox 3

Kai, thanks! When I follow those steps, on Linux, I get: WARNING: NS_ENSURE_TRUE(mSecurityInfo) failed: file ../../../../mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 955 WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../../mozilla/netwerk/protocol/http/nsHttpChannel.cpp, line 1015 Line 955 is: NS_ENSURE_TRUE(mSecurityInfo, NS_ERROR_FAILURE); in ProcessSTSHeader. Line 1015 is the NS_ENSURE_SUCCESS line here: rv = ProcessSTSHeader(); NS_ENSURE_SUCCESS(rv, rv); in nsHttpChannel::Connect. Both lines are wrong. The former assumes that we should have security info just because we have an https: URI; that's false for proxy CONNECT requests. The latter returns early from a method from which you are NOT allowed to return early; doing so violates the channel API contract. The right way to handle a fatal failure here is to call Cancel() with an appropriate error code followed by CallOnStartRequest.

Oh, both lines were added in bug 495115.

Sid, in nsHttpChannel::ProcessResponse() you have // If STS data is present, process it here. rv = ProcessSTSHeader(); NS_ENSURE_SUCCESS(rv, rv); I think you must analyze ProcessSTSHeader() and only return failure on fatal errors. A condition that causes you to stop processing of STS information shouldn't abort the other http processing. I think you should check function ProcessSTSHeader and change it to return NS_OK whenever you want to stop STS processing, without having encountered a fatal error.

Using this experimental patch and the steps-to-reproduce, I get the proxy auth prompt.

Comment on attachment 471022 [details] [diff] [review] experimental patch r- because of comment 23.

(In reply to comment #23) > Both lines are wrong. The former assumes that we should have security info > just because we have an https: URI; that's false for proxy CONNECT requests. Will there be a step after the proxy connect that gets to see the mSecurityInfo? When we connect to an HSTS host through a proxy we still need to be able to check the connection for certificate errors. If we don't get the certificate for the site, HSTS should drop the connection but if we do get the security info later, HSTS should look at the cert before deciding if the connection is okay.

> Will there be a step after the proxy connect that gets to see the > mSecurityInfo? I would think so... but you should be able to do an HTTP log of such a transaction and see for yourself what we think we're doing, right?

Hmm, I didn't realize during review. We should bypass ProcessSTSHeader+the failure check when mTransaction->SSLConnectFailed() returns PR_TRUE, that means we didn't go through the proxy yet.

I fixed some of the failures in nsHttpChannel::ProcessSTSHeader to be softer (return NS_OK, but assert). Also, in nsHttpChannel::Connect, I changed STS-only failures to be non-fatal, but assert. Finally, in nsHttpChannel::ProcessResponse, I updated the logic to avoid doing any STS stuff if mTransaction->SSLConnectFailed(). This line alone should take care of the NTLM auth problem, but the rest of the fixes were warranted by bz's sagelike advice in comment 23. :) I feel confident about the fix, and though I haven't tested with Kai's procedure above (funniness in my build, doing a clobber build now) it should work. I'll run those tests as soon as I possibly can, but wanted to post the patch in case someone else can do it sooner. kaie, bz: could you take a peek and let me know what you think of my proposed fix?

just confirmed that the patch (attachment 471210 [details] [diff] [review]) results in the expected behavior for Kai's test in comment 21.

Comment on attachment 471210 [details] [diff] [review] proposed fix Looks good to me.

Comment on attachment 471210 [details] [diff] [review] proposed fix I'm not a peer of netwerk, but the patch looks good to me and I can give you sr=kaie Would it make sense to turn the steps-to-reproduce and the fake-server-response into an automated test?

(In reply to comment #34) > Would it make sense to turn the steps-to-reproduce and the fake-server-response > into an automated test? I was thinking of it too. In mochitest we cannot override proxy settings, so it probably could not be a mochitest. In xpc-shell there seems to be a better chance, but we don't have ssl support (pending on me, bug 466524) so we cannot check the connection succeeded.

Here's a try server build for the patch in attachment 471210 [details] [diff] [review]: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/sstamm@mozilla.com-857ab5aad1ee/

(In reply to comment #36) > Here's a try server build for the patch in attachment 471210 [details] [diff] [review]: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/sstamm@mozilla.com-857ab5aad1ee/ I attempted to run the win32-Debug build, but I didn't have much luck. On start, I just get a error that says "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I saw that it's trying to load mozcpp19.dll and mozcrt19.dll, which aren't included in the build. I tried copying them from another nightly, but that didn't improve anything. Dependency Walker also says it needs MSVCP80D.DLL and MSVCR80D.DLL, but I don't have those. It looks like I'd need to install Visual Studio 2005 to get them installed correctly. I haven't tried yet, but I can later. Any chance of a non-debug build?

Usually the try server should produce non-debug builds, too. However, it seems that the build simply failed (maybe caused by some other breakage of the experimental code at the same time). Sid, would it make sense to simply retry the build?

Hm, yeah, build timeout, bummer. Re-pushed the build and will post a link to the builds in an hour or two when they start rolling in.

Not sure if this needs to block, but it has approval so I'm clearing the blocking nomination...

This definitely needs to block.

Well, the mobile builds are rolling in, but we're a bit backed up on Windows. When they show up they'll be here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/sstamm@mozilla.com-ad3eaca19f44/

There's a win32 optimized build that just finished. http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/sstamm@mozilla.com-ad3eaca19f44/tryserver-win32/

Running it now. So far it seems to be working fine. Heck, I can see this page! :) Gmail is working fine as well. I did get an alert at startup, right after it checked my Addons for updates: "The operation can not be completed because of an internal failure. A secure network communication has not been cleaned up correctly." I'm assuming that's unrelated though. I'll have to see if I can reproduce it.

Looks like that message is another known problem, so I won't worry about it (https://bugzilla.mozilla.org/show_bug.cgi?id=588511)

The new build works correctly also with my company proxy. I was really surprised how fast you guys fixed this, thank you all :)

It seems that FF 4b5 doesn't include this fix. Is there any "about:config" entry to disable the hsts protocol ?

> It seems that FF 4b5 doesn't include this fix. Nothing includes this fix yet; that's why the bug status is not "RESOLVED FIXED". > Is there any "about:config" entry to disable the hsts protocol ? No. Sid, is there a reason this hasn't been checked in yet? Are you waiting on something, or do you just need someone to push this?

I can land it.

(In reply to comment #50) > Sid, is there a reason this hasn't been checked in yet? Are you waiting on > something, or do you just need someone to push this? Ack. I thought I flagged it for checkin needed... Guess not. Yeah, I just need someone to check it in.

There's no workaround for this?

Pushed http://hg.mozilla.org/mozilla-central/rev/3beb281805be

euh... how must i install it on FF 4, please? Cause, you says that the problem is resolved but i would like this bug fix ;) Thank you

> how must i install it on FF 4, please? You either get a nightly build from http://nightly.mozilla.org/ (but be warned that these can be somewhat unstable!) or you wait for Firefox 4 beta 6 (which is set as the target milestone, and will be the beta that has this fix).

Just a comment to make, for the guys who still do not want to either go back to nightly builds or to beta 4, it started working fine for me as soon as I enabled private browsing mode. I am running beta 5 on Linux as well as Windows XP. As soon as I come out of private browsing mode, it will not open any page starting with https.

Yep, private browsing mode works fine in the old builds. Huh. Does that mean that STS isn't being used in private browsing mode? If so, I wonder if that's intended.

Yes. New STS information is not recorded in private mode because the sts permissions are like little one-bit cookies. I'm working on a better approach, but for now its just disabled.

(In reply to comment #57) > > how must i install it on FF 4, please? > You either get a nightly build from http://nightly.mozilla.org/ (but be warned > that these can be somewhat unstable!) or you wait for Firefox 4 beta 6 (which > is set as the target milestone, and will be the beta that has this fix). Do you guys have an ETA for beta 6?

> Do you guys have an ETA for beta 6? Freeze is this week. How long it takes after that depends on whether QA finds issues with it.

It's come back for me with beta 6 on Windows 7 Professional x86.

Andrea, the beta6 that was just released is a small patch release that only contains fixes for two bugs compared to beta5. What used to be planned as beta6 is now called beta7, without a schedule change (past the obvious "the code freeze didn't happen on Friday, aiming to get to it this week" thing that wasn't affected by the patch release).

Still not fixed in beta 6(I completly wiped all mozilla products/settings after uninstall, including the hidden documents and settings folders and installed again) When I try to check for update it says malformed xml, I don't know about other people...

Jamie, please see comment 69.

So uh Mozilla, when is 4b7 going to arrive? Because according to your own wiki (https://wiki.mozilla.org/Firefox/4/Beta) 4b8 should already have been out last Friday. This bug is pretty much preventing me (and a goodly amount of other users) from using Firefox at the moment so I'm confused as to why you haven't hastened to roll out a fix for it.

The dates are tentative and not final, there are more bugs blocking the release of FF4b7 (about 51) and 758 before final is ready see here: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking2.0%3Afinal,beta

> so I'm confused as to why you haven't hastened to roll out a fix for it. Honestly, because the relative number of beta users affected is small enough that we're still getting useful beta feedback and because beta7 is not ready yet... We could spend several days of work getting an interim beta with just this fix out the door, or we could focus that work on getting beta7 ready. And of course non-beta users aren't affected at all, right? I realize this is annoying if you want to test current beta builds; I'm afraid your options are either to use the last beta that doesn't have the bug or to use a nightly. For what it's worth, the nightlies are quite stable; if you're not affected by one of the remaining 16 beta7 blockers (or are affected by them less than by this bug), it might be well worth your time to run them.