Closed Bug 1329304 Opened 8 years ago Closed 8 years ago

chrome.extension.getBackgroundPage doesn't work in Private Mode

Categories

(WebExtensions :: Untriaged, defect)

Product:
WebExtensions
Component:
Untriaged
Version:
50 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: alexeiatyahoodotcom+mzllbgzll, Unassigned)

References

Details

(Keywords: dev-doc-complete)

Attachments

(2 files)

Screenshot from 2017-01-06 18:08:55.png
74.08 KB, image/png
Details
example extension to easy reproduce the issue
9.13 KB, application/x-zip-compressed
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36 Steps to reproduce: The new Web Extensions version of Privacy Badger is experiencing an issue where calls to chrome.extension.getBackgroundPage return null in the browser popup context opened in Private Browsing Mode windows. Please see https://github.com/EFForg/privacybadger/issues/1060 for the original Privacy Badger issue.
This is intentional. Private browsing windows can't access the contents of non-private windows, so you'll need to communicate with your background page in some other way.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Kris, would chrome.extension.sendRequest work for this do you think?
(In reply to Cooper Quintin from comment #2) > Kris, would chrome.extension.sendRequest work for this do you think? No, that API is deprecated in Chrome, so it's not implemented in Firefox. You can use runtime.sendMessage or runtime.connect, though.
I am not certain, but I think the same code works in Incognito windows in Chrome. Which would be inconsistent behavior among Web Extensions platforms.
Also, if an addon can work around broken chrome.extension.getBackgroundPage in private window browser popups by using messaging, what's the point of breaking chrome.extension.getBackgroundPage in private window browser popups? I might be missing something though.
(In reply to Alexei from comment #4) > I am not certain, but I think the same code works in Incognito windows in > Chrome. Which would be inconsistent behavior among Web Extensions platforms. It only works in Chrome in split incognito mode, which we don't support.
(In reply to Kris Maglione [:kmag] from comment #6) > (In reply to Alexei from comment #4) > > I am not certain, but I think the same code works in Incognito windows in > > Chrome. Which would be inconsistent behavior among Web Extensions platforms. > > It only works in Chrome in split incognito mode, which we don't support. Privacy Badger uses "spanning"[1] and this scenario works in Chrome ... Attaching a screenshot of a popup being debugged in an Incognito window. 1.: https://github.com/EFForg/privacybadger/blob/6f0745bb9af0d3b4fa78a7217e8c17b3ccf32763/manifest.json#L11
chrome.extension.getBackgroundPage works in an extension browser popup context in an Incognito window in Chrome. The extension (Privacy Badger) declares "spanning" mode in its manifest.
Well, regardless, it's not possible for a non-private window to directly interact with a private window, or vice versa, in Firefox.
This breaks our extension as well where we need to reference background page properties from our browser action window. Private browsing modes in Chrome/Opera work as expected.
It would be very helpful if the Mozilla / Firefox documentation was updated to reflect this difference. Specifically, this page - https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities
Which API can we use to message between the browserAction page and the background page?
As my report (1398245) was marked as a dup, can this issue be reconsidered once more? Danny's question is still valid and there is no alternative method to send any data to the background script. I don't want to duplicate data in each sidebar, just because of this issue. No direct data exchange between windows is possible, so I have to save it to storage or something and load it in another window. Moreover I have chrome listeners in background instead of duplicating them in each sidebar. It saves cpu cycles and memory. Another issue is that, loading data from storage would cause longer loading time for the sidebar to open. I'd like to have an option (like in chromium) to allow communication from private windows.
(In reply to kroppy from comment #14) > As my report (1398245) was marked as a dup, can this issue be reconsidered > once more? No. It is literally not possible for a private window to access a private one. This restriction is built into the platform at several levels. > Danny's question is still valid and there is no alternative method to send > any data to the background script. Of course there is. You can always communicate with the background page using runtime.sendMessage.
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #15) > No. It is literally not possible for a private window to access a private one. > This restriction is built into the platform at several levels. Why, so many restrictions? > Of course there is. You can always communicate with the background page > using runtime.sendMessage. omg... It means months of work. I will have to rethink a lot of logic and angry people will have to wait. Thanks anyway :(
OMG!!! Please update the documentation here: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/getBackgroundPage and place there HUGE, EXTREMELY HUGE warning that this method is COMPLETELY USELESS!!! because it won't work in private mode! I'm sorry, I've got a bit emotional... I've just spend whole day refactoring my common methods form options page, dials page and pop-up page in my background script only to find out I won't work in private mode.
Could the "incognito": "split" key solve this, apart from new potential problems? https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/incognito Or maybe a property like "openInNonePrivateWindow" for the options_ui key. This would be an easy workaround, at least for option pages. If it's possible to open the options page in a new window, then this could even be implemented by the developer itself, by checking the extension.inIncognitoContext. Btw I guess this "problem" also applies to the getViews method, maybe the documentation should be updated there too. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/extension/getViews
If you can use runtime.sendMessage to communicate with the background page, then you can access any data the background page has. It's just PITA to do, slower in terms of performance, more complex code and a lot of work to refactor existing extensions that work perfectly on Chrome and Vivaldi. What good does it then do that getBackgroundPage() returns null? I don't get it so please explain and help me understand. I could list a lot of harmful things that it causes but I guess they are obvious enough to everyone.
Thanks for the input, but at this point, these extra comments aren't helping. As Kris has pointed out in comment 1 and comment 9 there would have to be major structural changes in Firefox to make this happen. Our next goal is likely to complete bug 1380809 which would allow improved private browsing support. Please note that the documentation for that page has been updated as per comment 17.
Keywords: dev-doc-needed
The documentation should also be updated for https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/extension/getViews Should I created a bug for this? Thanks
(In reply to zepeuj from comment #23) > The documentation should also be updated for > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/extension/ > getViews > Should I created a bug for this? > > Thanks Well you can just update it yourself. No need to involve more people into this...
(In reply to juraj.masiar from comment #24) > Well you can just update it yourself. No need to involve more people into > this... I didn't know. I'll do it. Thanks
Product: Toolkit → WebExtensions
To save anyone some testing time, trying to get around this by sending the popup or background page's `window` object using `runtime.sendMessage` or `runtime.connect` will not work, it errors with `DataCloneError: The object could not be cloned.`

The problem is understandable, the browser is designed like this and it is not possible... BUT it is not possible because it was bad designed. It has no sense at all this behavior and should be addressed. Bug (because it is a bug, not a feature) opened 4 years ago and no fix yet.

(In reply to dcanofr from comment #29)

The problem is understandable, the browser is designed like this and it is not possible... BUT it is not possible because it was bad designed. It has no sense at all this behavior and should be addressed. Bug (because it is a bug, not a feature) opened 4 years ago and no fix yet.

I would say it should never existed in the first place. It's better to keep things encapsulated (less spaghetti).
Anyway, there are workarounds, for example:

  1. using ES6 modules you can simply import common functions into different parts of your extension
  2. if you need something from background script, you can use runtime.sendMessage to get what you need. Example.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: