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

RESOLVED INVALID

Status

RESOLVED INVALID
2 years ago
4 months ago

People

(Reporter: alexeiatyahoodotcom+mzllbgzll, Unassigned)

Tracking

({dev-doc-complete})

50 Branch
dev-doc-complete

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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
Last Resolved: 2 years ago
Resolution: --- → INVALID

Comment 2

2 years ago
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.
(Reporter)

Comment 4

2 years ago
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.
(Reporter)

Comment 5

2 years ago
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.
(Reporter)

Comment 7

2 years ago
(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
(Reporter)

Comment 8

2 years ago
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.

Comment 10

2 years ago
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.

Comment 11

2 years ago
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

Comment 12

2 years ago
Which API can we use to message between the browserAction page and the background page?
Duplicate of this bug: 1398245

Comment 14

2 years ago
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.

Comment 16

2 years ago
(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 :(

Comment 17

2 years ago
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.
Duplicate of this bug: 1401117

Comment 20

2 years ago
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

Comment 21

2 years ago
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.

Comment 22

2 years ago
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

Comment 23

a year ago
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

Comment 24

a year ago
(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...

Comment 25

a year ago
(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

Updated

a year ago
Duplicate of this bug: 1428788

Updated

9 months ago
Product: Toolkit → WebExtensions

Comment 28

6 months ago
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.`
You need to log in before you can comment on or make changes to this bug.