Closed Bug 1394807 Opened 7 years ago Closed 7 years ago

Tab pages for OOP extensions don't work when e10s is disbled

Categories

(WebExtensions :: General, defect)

56 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1393150

People

(Reporter: mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: I have three files: background.js, /foo/bar.html, and /foo/bar.js. In background.js: function writeSuccessful () { console.log ("Write successful."); browser.tabs.create({url : "/foo/bar.html"}); } function writeFailed (error) { console.log(`Error: ${error}`); } browser.storage.local.set({"storageTest" : "BLAH"}).then(writeSuccessful, writeFailed); In /foo/bar.html .... <script src="storageTest.js" type="text/Javascript"></script> </body> </html> In storageTest.js: var readSuccessful = function (savedObj) { console.log ("Read successful."); } var readFailed = function (error) { console.log ("Reading failed."); } document.addEventListener("DOMContentLoaded", function () { console.log ("Getting stored stuff."); var getting = browser.storage.local.get("storageTest").then(readSuccessful, readFailed); }); console.log ("/foo/bar.js loaded"); ---------------------------------------------- This bug seems to have appeared in 56.0b2 Developers Edition. Actual results: In the Browser Console: Write successful background.js:2 /foo/bar.js loaded bar.js:12 Getting stored stuff bar.js:9 Expected results: In the Browser Console: Write successful background.js:2 /foo/bar.js loaded bar.js:12 Getting stored stuff bar.js:9 Read successful. bar.js:2
Note: I've tried this in both 64 bit and 32 bit on Windows. The problem occurs in both.
Also note I've tried the following: * The stored value _can_ be retrieved in the background.js script. ie: The value _is_ saving to storage. * If I load a content script (from manifest.json, or browser.tabs.executeScript()), that content script _can_ retrieve the storage. So I know the value _is_ being stored. In manifest.json, I tried adding: "content_scripts": [ { "matches": ["*://*/foo/bar.html"], "js":["/foo/storageTest.js"] } ] In this case, /foo/storageTest.js doesn't even load. (That may even be another bug.)
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
After playing with some preferences regarding the Browser Console, I found these errors were appearing when browser.storage.local.get() was executing: Attempt to create privileged extension parent from incorrect child process ExtensionParent.jsm:646 createProxyContext resource://gre/modules/ExtensionParent.jsm:646:15 receiveMessage resource://gre/modules/ExtensionParent.jsm:598:11 Error: WebExtension context not found! ExtensionParent.jsm:778:13
Do you have e10s support enabled or disabled? Could you go to about:support and tell us the values for Multiprocess Windows and Web Content Processes please?
Flags: needinfo?(mozilla)
Summary: Storage API doesn't work on an internal .js called with tabs.create(). → Tab pages for OOP extensions don't work when e10s is disbled
Blocks: webext-oop
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
(In reply to Andy McKay [:andym] from comment #4) > Do you have e10s support enabled or disabled? Could you go to about:support > and tell us the values for Multiprocess Windows and Web Content Processes > please? This is what I have: Multiprocess Windows 0/1 (Disabled by accessibility tools)
Flags: needinfo?(mozilla)
(In reply to mozilla from comment #6) > (In reply to Andy McKay [:andym] from comment #4) > > Do you have e10s support enabled or disabled? Could you go to about:support > > and tell us the values for Multiprocess Windows and Web Content Processes > > please? > > This is what I have: > > Multiprocess Windows 0/1 (Disabled by accessibility tools) And I have nothing for Web Content Processes in about:support.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.