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

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?

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.

This addon appears to be functioning correctly in e10s.

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.

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?

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.

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.

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.

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).

With Firefox 57 only WebExtensions are permitted and are, by default, e10s compatible.