Having discussed the ramifications of bug 723353 some more, Ehsan and I have decided that we should eliminate the setter and make the getter operate on the current tab instead of the entire window. Even though we are not planning to ship with a per-tab PB implementation, we don't want to deny addon authors the ability to create one. This means that our code that uses the JS API to determine PB status must not break in the presence of a per-tab implementation, hence the switch to currentTab. Since the prospect of an asymmetric API that checks the current tab but sets the whole window is unappealing, we'll remove the setter and manipulate docshells when necessary in the chrome code. This will require updating a couple tests that use this new setter.
Please assign this to me.
Created attachment 631231 [details] [diff] [review] Patch v1
Comment on attachment 631231 [details] [diff] [review] Patch v1 Looks great, but you have a small mistake: you need to flip the order of arguments passed to setPrivateWindow in the test files as well.
Created attachment 631239 [details] [diff] [review] Patch v2
Comment on attachment 631239 [details] [diff] [review] Patch v2 Looks great! r=me
Comment on attachment 631239 [details] [diff] [review] Patch v2 >+ return gBrowser.selectedTab.linkedBrowser >+ .docShell.QueryInterface(Ci.nsILoadContext) >+ .usePrivateBrowsing; I hate to spoil your fun but gBrowser has a .docShell property...
@Neil But if I use |gBrowser.docShell|, wouldn't that refer to the docShell of the current window, while we need to use the use the PB mode flag per tab, for which we need to access the docShell of each tab.
https://hg.mozilla.org/mozilla-central/rev/3e22b1ebabf4 (Merged by Ed Morley)
That docShell property is defined here: <http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2364> and it seems to do what we want. Saurabh, do you want to file a follow-up bug to fix this? :-)