Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090301 Shiretoko/3.1b3pre ID:20090301020400 When you start or stop the Private Browsing mode while staying in a window-less state there will be opened two windows for each of those actions. Steps: 1. Check that one window is open and open some tabs 2. Close the window 3. Start Private Browsing mode 4. Close all open windows 5. Close Private Browsing mode After step 3 and step 5 two new windows will be opened. Both states differ a bit so lets split it in two points: * After step 3 you will have a window with the about:privatebrowsing page open and another one which has an untitled tab open * After step 4 you will have a window with all your opened tabs from step 1 and a further window with an untitled tab

This bug was maybe being hidden by bug 473860 but wasn't caused by it. The problem is that we set a state for the transition even when there isn't a current state. Fix upcoming.

Comment on attachment 364828 [details] [diff] [review] refactor a little, do things when it's sane to do them >diff --git a/browser/components/privatebrowsing/src/nsPrivateBrowsingService.js >+ // a bit of belt-and-suspenders, make sure we still have the right window >+ // if this throws, we have a problem with the line above, so don't need to >+ // null-check anymore >+ browser = this._getBrowserWindow().gBrowser; I don't see how this could possibly return a different window than the one we already retrieved, given that we haven't returned to the main event loop yet. Also I think it would be clearer to have separate browserWindow and tabbrowser variables, rather than just reusing "browser" for both. Otherwise, this looks OK.

Landing?

(In reply to comment #3) > I don't see how this could possibly return a different window than the one we > already retrieved, given that we haven't returned to the main event loop yet. I didn't realize that setBrowserState can open/close windows. I still don't think that switch can happen synchronously (and I'm not sure nsWindowMediator's hash would be updated in that case anyways), but I suppose it doesn't really hurt to leave the code as-is.

Given this landing, is this fixed-1.9.1 (and no more [needs landing]) now? http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3cb9d996fcd7

http://hg.mozilla.org/mozilla-central/rev/c71c70056691 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3cb9d996fcd7 this is now fixed, branch and trunk.

(In reply to comment #9) > http://hg.mozilla.org/mozilla-central/rev/c71c70056691 > http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3cb9d996fcd7 > > this is now fixed, branch and trunk. -> RESOLVED FIXED

Verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre ID:20090304022008