Closed Bug 592197 Opened 14 years ago Closed 14 years ago

SSL pages don't work when using a NTLM proxy

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: krzysztof.krason, Assigned: geekboy)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

proposed fix
5.64 KB, patch
bzbarsky
: review+
KaiE
: superreview+
bzbarsky
: approval2.0+
Details | Diff | Splinter Review 
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.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Reporter, are you willing to try to narrow down when this problem appeared using nightly builds?
blocking2.0: --- → ?
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?
Summary: SSL pages don't work when using a NTML proxy → SSL pages don't work when using a NTLM 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
Exact range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a623cc1c5e7&tochange=4a6ee9e82945

My money's on STS.
Blocks: 495115
Status: UNCONFIRMED → NEW
Ever confirmed: true
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>
Assignee: nobody → sstamm
(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?
Keywords: regression
(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.
Attached patch experimental patch (obsolete) — — Splinter Review 
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.
Attachment #471022 - Flags: review-
(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.
Status: NEW → ASSIGNED
> 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.
Attached patch proposed fix — — Splinter Review 
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?
Attachment #471022 - Attachment is obsolete: true
Attachment #471210 - Flags: review?(kaie)
Attachment #471210 - Flags: feedback?(bzbarsky)
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.
Attachment #471210 - Flags: review+
Attachment #471210 - Flags: approval2.0+
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?
Attachment #471210 - Flags: superreview+
Attachment #471210 - Flags: review?(kaie)
Attachment #471210 - Flags: feedback?(bzbarsky)
(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.
(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...
blocking2.0: ? → ---
This definitely needs to block.
blocking2.0: --- → final+
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/
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
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: