Closed Bug 1501006 Opened 4 years ago Closed 4 years ago

windows.create can create container tab even in perma-private browsing mode


(WebExtensions :: Frontend, defect, P3)

64 Branch


(firefox-esr60 unaffected, firefox63 unaffected, firefox64 verified, firefox65 verified)

Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- verified
firefox65 --- verified


(Reporter: robwu, Assigned: robwu)



(Keywords: regression)


(3 files)

Bug 1393570 allows extensions to create windows consisting of container tabs.

Currently, container tabs are not supported when perma-private browsing mode is enabled (bug 1320757).
However, with the extension API from bug 1393570, it is possible to create a container tab despite perma-private browsing mode being enabled, and the resulting tab data is persisted to the disk (which violates the privacy assumptions of PBM).

1. Start Firefox, visit about:config and set
   browser.privatebrowsing.autostart to true
   (this is equivalent to visiting about:preferences and setting History to "Never remember history")
2. Restart Firefox.
3. Load attached extension, e.g. at about:debugging.
4. Click on the extension button (green puzzle piece in toolbar).
5. Enter in the input field and press on the "Open URL in new container tab" button.

- Nothing should happen. The global error console should contain an error from the windows.create call.

- A new window is opened, with a container tab.
- The data is persisted to disk: Open the profile directory (which you can find at about:support), and search for the website that you have just opened:

$ grep -rl
I'm going to fix the extension API implementation, but the fact that setting a non-default userContextId can bypass perma-PBM also looks like a bad bug on its own.
See Also: → 1501244
Until container tabs are supported in private browsing mode
(bug 1320757), extensions should not be able to open container tabs when
perma-private browsing mode is off.
The first patch fixes the regression, and I intend to uplift this.

The second patch is a drive-by fix to ensure that cookieStoreId can only be used if contextual identities are enabled.
The latter is a bug, but there is a chance that extensions have started to depend on it, so I'll let that ride the train.
Priority: -- → P3
Pushed by
Reject cookieStoreId in perma-private browsing mode r=mixedpuppy
Reject cookieStoreId when contextual identities are disabled r=mixedpuppy
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
I verified that the bug has been fixed:

Broken: Firefox 65.0a1 20181028102553
Fixed : Firefox 65.0a1 20181029230149, the console (via the Debug button at about:debuggingP) shows the following message after running the STR:
Error: "Contextual identities are currently disabled"
Comment on attachment 9019349 [details]
Bug 1501006 - Reject cookieStoreId in perma-private browsing mode

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1393570

User impact if declined: Container tabs can be opened by extensions even if the preference to enable container tabs feature is off.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: none

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): 

String changes made/needed:
Attachment #9019349 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Flags: in-testsuite+
Comment on attachment 9019349 [details]
Bug 1501006 - Reject cookieStoreId in perma-private browsing mode

[Triage Comment]
Fixes extensions being able to open container tabs even if the preference to enable container tabs feature is off. Approved for 64.0b6.
Attachment #9019349 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I managed to reproduce this on Firefox 64.0b5.

The bug is no longer reproducible on Firefox 64.0b6 and Nightly 65.0a1 (2018-11-01) so I'll mark it as verified.
You need to log in before you can comment on or make changes to this bug.