Open Bug 1282021 Opened 7 years ago Updated 4 months ago does not work in background pages


(WebExtensions :: General, defect, P3)

49 Branch


(Not tracked)


(Reporter: cgarnant, Assigned: kmag)



(Whiteboard: investigate, triaged)


(1 file)

Attached file bugz.txt
User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31

Steps to reproduce:

The attached background page works in a Chrome extension. It negotiates with the content script to determine if a page action is valid (the dflibg javascript library is loaded and its sdk module is active in the current 'tab'), upon an 'accept' - see line 37:43 in the attached daemon.js (background page script) it constructs the full url of the extension's dataflow debugger GUI (included in the manifest (sdkfirefly.html), and attempts to open the HTML.

Actual results:

 the fails,
neither the background page debugger window, nor the browser console shows no errors, warnings, or other indications of any kind as to why the extension page did not open

Expected results:

the page should open - it does in chrome.

to reproduce, just build a bkgrnd script whose pageAction function does a for a url that points to a file.html included in the extension and identified as a web-accessible-resource
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
The simplest workaround is to use instead of
OS: Linux → All
Hardware: x86_64 → All
Summary: HTML resource in web-accessible-resources not accessible → does not work in background pages
Kris: Thank you.  I did manage a workaround but using  [type:panel]; ('browser') object for some strange reason, (probably me), seems to come up undefined in FF49 Dev Edition.
The only problem with that workaround is then window.opener is undefined.
I can work around in both Chrome/FF with port connections, and the extension foreground does not open any sub-panels that need window.postMessage()-based dataflow.
But it might be an issue for others.

Again, thank you for the suggestion
Ever confirmed: true
matt, were you looking into this to look into
Assignee: nobody → mwein
Flags: needinfo?(mwein)
Whiteboard: investigate
We already do something similar for `window.alert`, here is where we redefine it for the background page (in this case we redefine it to log in the webconsole):

The above function can be probably very helpful as a source of inspiration, and probably it is where we will actually implement this.
Kris pointed out that this might not be the right way to go here; that the right solution might be much more complicated, involving I'm reassigning this to Kris to investigate as he is better equipped to handle this issue.
Assignee: mwein → kmaglione+bmo
Flags: needinfo?(mwein)
This turns out to be even hairier than I expected. We're probably going to need a completely different strategy for remote browsers, so rather than have to implement this twice, I'm going to wait for bug 1287004 to land first.
Depends on: 1287004
Whiteboard: investigate → investigate, triaged
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P2
webextensions: --- → ?
webextensions: ? → ---
Assignee: kmaglione+bmo → nobody
Hi there, what is the workaround for this today? Neither nor seems to exist. My use case is to prompt the user to login to the extension first before activating the functionality.
Looks like is the way to go.
Assignee: nobody → kmaglione+bmo
Priority: P2 → P3
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.