Open Bug 1282021 Opened 4 years ago Updated 2 years ago

window.open does not work in background pages

Categories

(WebExtensions :: General, defect, P3)

49 Branch
defect

Tracking

(Not tracked)

People

(Reporter: cgarnant, Assigned: kmag)

References

Details

(Whiteboard: investigate, triaged)

Attachments

(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 window.open() 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 window.open() 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 browser.windows.open instead of window.open.
OS: Linux → All
Hardware: x86_64 → All
Summary: HTML resource in web-accessible-resources not accessible → window.open does not work in background pages
Kris: Thank you.  I did manage a workaround but using chrome.windows.open  [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
Status: UNCONFIRMED → NEW
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):

http://searchfox.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#669

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 http://searchfox.org/mozilla-central/source/browser/base/content/browser.js#933. 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
Duplicate of this bug: 1296483
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P2
Duplicate of this bug: 1338845
webextensions: --- → ?
webextensions: ? → ---
Assignee: kmaglione+bmo → nobody
Hi there, what is the workaround for this today? Neither browser.windows.open nor chrome.windows.open seems to exist. My use case is to prompt the user to login to the extension first before activating the functionality.
Looks like browser.windows.create is the way to go.
Assignee: nobody → kmaglione+bmo
Priority: P2 → P3
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.