1282021 - window.open does not work in background pages

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Chrys Garnant]

Attachment: 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

Comment 1

[Kris Maglione [:kmag]]

The simplest workaround is to use browser.windows.open instead of window.open.

Comment 2

[Chrys Garnant]

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

Comment 3

[:shell escalante]

matt, were you looking into this to look into

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

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.

Comment 5

[Matthew Wein [:mattw]]

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.

Comment 6

[Kris Maglione [:kmag]]

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.

Comment 9

[Jonathan L]

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.

Comment 10

[Jonathan L]

Looks like browser.windows.create is the way to go.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 12

[Paul Hrdlicka]

Attachment: same problem

Thanks from itgraphreswa1975.