If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"Self-Destructing Cookies" add-on does not work with e10s

REOPENED
Unassigned

Status

()

Firefox
Extension Compatibility
REOPENED
3 years ago
2 months ago

People

(Reporter: phillyphong, Unassigned)

Tracking

(Depends on: 1 bug, {addon-compat})

Trunk
addon-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+)

Details

(URL)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20140723030202

Steps to reproduce:

browser.tabs.remote.autostart to true
enable Self-Destructing Cookies



Actual results:

Destructs cookies from current active tab. Did not test thoroughly, but this affects Twitter.


Expected results:

Multi-process Firefox
(Reporter)

Updated

3 years ago
Keywords: addon-compat
OS: Windows 7 → Windows 8.1
Version: 26 Branch → 34 Branch
Component: Untriaged → Extension Compatibility
tracking-e10s: --- → ?
tracking-e10s: ? → +
Summary: Self-Destructing Cookies e10s → "Self-Destructing Cookies" add-on does not work with e10s
Version: 34 Branch → Trunk

Comment 1

3 years ago
After a cursory examination, it seems that this is due to two functions in the addon-SDK failing when e10s is enabled. SDC uses the following two events to keep track of the current state of the tabs contents:

https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/tabs#ready_2
https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/page-mod#attach

When e10s is enabled, tabs:ready only fires for the first open tab. Page-mod#attach seems to be entirely dysfunctional.
Zombie: will your Add-on SDK work fix tabs:ready event or page-mod attach?
page-mod fix is in the works, bug 1066685.
tabs:ready should work ever since bug 1023326. 

unfortunately we haven't been able to enable all the tests for everything yet, so something might have regressed.. :(

Ove can you please provide some more detailed Steps To Reproduce tab:ready not working?
Flags: needinfo?(accounts)

Comment 4

3 years ago
Thank you for helping. I just updated my nightly build. As of 35.0a1 (2014-09-29), built from https://hg.mozilla.org/mozilla-central/rev/9d66436af432 both problems still exist. I'm not sure if the pagemod fix has already landed, but it throws an exception whenever I load a page:

-------------------

console.error: self-destructing-cookies: 
  Message: [Exception... "Failure arg 0 [nsIScriptSecurityManager.isSystemPrincipal]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/sandbox.js :: WorkerSandbox :: line 113"  data: no]
  Stack:
    WorkerSandbox@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/sandbox.js:113:28
constructor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/heritage.js:145:22
@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:142:24
dispatch@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/method/core.js:119:11
WorkerConstructor@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/content/worker.js:74:6
constructor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/heritage.js:145:22
createWorker@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/page-mod.js:204:15
onContent@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/page-mod.js:242:4
onContentWindow@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/page-mod.js:185:6
Observer<.observe@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///home/ove/.mozilla/firefox/bpy2kw5r.Nightly/extensions/jid0-9XfBwUWnvPx4wWsfBWMCm4Jj69E@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/system/events.js:72:6
ObserverParent.notify@resource://gre/modules/RemoteAddonsParent.jsm:308:8
ObserverParent.receiveMessage@resource://gre/modules/RemoteAddonsParent.jsm:298:8

----------------------

As for tabs#ready only firing for the first open tab, my diagnosis was not precise enough. The root cause seems to be that tabs#open does not fire at all, so my code can only attach an event-listener to the first, pre-existing, tab and thus only catches the ready-events for this tab.
Flags: needinfo?(accounts)
Depends on: 1100035
Duplicate of this bug: 1100035
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

2 years ago
This addon appears to be functioning correctly in e10s.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Comment 7

2 years ago
SDC is affected by #1130859 when e10s is enabled. LocalStorage support is broken because no storage events are sent. I'm not sure how to work around this issue.

Comment 8

9 months ago
Given Ove's last comment, should the status of this ticket be changed to REOPENED, or is it effectively RESOLVED WONTFIX because of bug 1130859? Is there any way for SDC to work with e10s?

Comment 9

9 months ago
Well, if we can't get them to reconsider Bug 1130859, it's always possible to propose a new WebExtensions Experiments API that does the same thing but actually works as a stunt to draw attention to the fact that, yes, it IS needed functionality.

Comment 10

9 months ago
I have little understanding of the technical details of how Firefox handles localStorage, sessionStorage, and cookies and how e10s affects all of that. My main interest is just to see Self-Destructing Cookies keep working. Honza's comment on bug 1130859 makes the situation sound dire, but he is talking about sending storage events (with objects) across processes. I guess this is the API that Self-Destructing Cookies uses right now, but isn't it more than is needed for Self-Destructing Cookies to do what it is supposed to do? I would think that all it needs is the ability to query and remove the storage when the page location changes or the tab is closed (the comments on this article may be of interest here: http://www.ghacks.net/2016/11/27/firefox-53-exclusive-content-process-for-local-files/).

Regarding a WebExtensions API, I think it would be good to add one. In fact, an extension to allow for the querying and removal of local storage on a per-origin basis to the Chromium extensions API has been proposed and approved (see the discussion and linked proposal here: https://groups.google.com/a/chromium.org/forum/#!msg/apps-dev/-JuS6Kfff4c/peEsbyy4qA8J). The proposal is a couple of years old but if you look through the bug tracker (such as in this ticket and a few linked to it: https://bugs.chromium.org/p/chromium/issues/detail?id=78093) you can see that the author is still actively working towards adding the API. That proposal extends the browsingData.remove API. The WebExtensions equivalent appears to be under active development in bug 1321303. I'm not sure how the Firefox team feels about adding API's that have been proposed and approved for Chromium but not yet implemented.

Comment 11

9 months ago
If that makes any difference, SDC does not need the objects that are attached to the StorageEvents - the domain in the URL attribute is sufficient.

Updated

8 months ago
Blocks: 1331308
Still missing LocalStorage support in e10s. Depends on the tracking bug for IndexedDB/LocalStorage clearing support in the browsingData API (although I'm not sure, whether or not that bug includes implementing support for removal on a per-origin basis).
Status: RESOLVED → REOPENED
Depends on: 1333050
OS: Windows 8.1 → Unspecified
Hardware: x86_64 → Unspecified
Resolution: FIXED → ---
Depends on: 1340511
No longer depends on: 1100035
Depends on: 1100035
No longer depends on: 1333050
You need to log in before you can comment on or make changes to this bug.