Bug 463256 which caused SSL pages not to load after transitioning the private browsing mode was fixed by a drastic approach: restarting the entire Necko library on transitions of private browsing mode. This is absolutely less than perfect but it was the best solution at hand back when bug 463256 was fixed. This causes problems such as bug 488772, Chatzilla (and possibly other extensions which open their own network connections) to drop its connection when turning Private Browsing mode on or off, and also caused some craziness with our unit test frameworks (see bug 486640). Bug 480619 provides a clean fix for the underlying issue, and once that bug is fixed, we can mostly backout the changes committed as part of bug 463256 and Necko will behave correctly once the private browsing mode is changed. This is a really really wanted fix for 1.9.1. I'm requesting blocking to get this on radar, but I expect this to make it's way into a dot release.

This can't end up blocking+ if it's blocked on a bug that's blocking-...

(In reply to comment #1) > This can't end up blocking+ if it's blocked on a bug that's blocking-... Yes... wanted1.9.1.x flag is disabled for me on all bugs, otherwise I would choose that instead...

The patch I have for this bug enables the sslsite transition test, so it would fix bug 486640 as well.

This patch removes the offline code magic, enables the sslsite transition test, and adjusts the xpcshell test to make sure no offline mode change happens when changing the private browsing status.

Verified fixed on trunk with the debug build Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090711 Minefield/3.6a1pre ID:20090711205434. I made a test-run with the existent Mozmill tests for Private Browsing. All were processed to the end now. It would be fantastic to get the fix in 1.9.1 so we can run functional tests for one of our major new features.

This can't be taken on 1.9.1.1 until bug 480619 (current status is approval191-) is taken, so someone should probably request approval on that bug first...

The change for this bug is suspected as a possible cause of bug 503418, and/or bug 489880, which are seen only on the trunk where this patch was committed.

(In reply to comment #8) > The change for this bug is suspected as a possible cause of bug 503418, > and/or bug 489880, which are seen only on the trunk where this patch was > committed. See bug 503418 comment 29.

Comment on attachment 386259 [details] [diff] [review] Patch (v1) Please renominate once we can determine definitively if this was or was not the cause of bug 503418

Comment on attachment 386259 [details] [diff] [review] Patch (v1) (In reply to comment #11) > (From update of attachment 386259 [details] [diff] [review]) > Please renominate once we can determine definitively if this was or was not the > cause of bug 503418 Based on bug 503418 comment 32 and bug 503418 comment 34, this is not the cause of bug 503418, so I'm nominating again. Please note that the test case for bug 480619 has also landed, and approval on this requires approval on bug 480619 as well.

Comment on attachment 386259 [details] [diff] [review] Patch (v1) Approved for 1.9.1.4, a=dveditz for release-drivers

Verified fixed with our Mozmill tests and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090831 Shiretoko/3.5.4pre ID:20090831030742