Open Bug 1282021 Opened 4 years ago Updated 2 years ago
.open does not work in background pages
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
matt, were you looking into this to look into
Assignee: nobody → mwein
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
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
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P2
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.
You need to log in before you can comment on or make changes to this bug.