Closed Bug 1208563 Opened 9 years ago Closed 9 years ago

Implement chrome.extension.inIncognitoContext property

Categories

(WebExtensions :: Untriaged, defect, P3)

defect

Tracking

(firefox44 fixed)

RESOLVED FIXED
mozilla44
Tracking Status
firefox44 --- fixed

People

(Reporter: callahad, Assigned: evilpie)

References

(Blocks 1 open bug)

Details

(Keywords: DevAdvocacy, Whiteboard: [extension])

Attachments

(1 file)

Reference: https://developer.chrome.com/extensions/extension#property-inIncognitoContext This is used by the Chrome version of the Reddit Enhancement Suite add-on. The Jetpack version uses sdk/private-browsing's isPrivate(window) function for equivalent functionality.
Assignee: nobody → evilpies
So we have actually implemented this already for content scripts. And that seems to be hit when I inline view an image on reddit with RES. When was this undefined? The documentation claims we should implement this for tabs as well. Additionally I think it also makes sense for popups, because we reload these every time anyway.
I think the one part here is that browser.extension is defined in ext-extension.js, which is part of toolkit. That part of the code isn't supposed to know about tabs or popups. However, extensions.registerAPI can be used to extend the API arbitrarily. So you can use extensions.registerAPI from ext-tabs.js to add inIncognitoMode to browser.extension. And you can use the currentWindow function from there to get the current XUL window.
Attached patch wip (deleted) — Splinter Review
I had written this patch before.
Comment on attachment 8666418 [details] [diff] [review] wip Review of attachment 8666418 [details] [diff] [review]: ----------------------------------------------------------------- This is actually just as good. It does bring up one issue. Right now we're not loading the browser action pop-up in private browsing mode if the window is private. We should probably do that.
This may be a documentation bug instead of an implementation bug :) https://wiki.mozilla.org/WebExtensions says "we support only getBackgroundPage and getURL," so I didn't actually try the inIncognitoContext API.
>Right now we're not loading the browser action pop-up in private browsing mode if the window is private. Seems complicated to do right now. They API is not accessible to JS.
(In reply to Bill McCloskey (:billm) from comment #4) > Right now we're not loading the browser action pop-up in private browsing mode > if the window is private. We should probably do that. It seems like Chrome does that conditionally based on whether or not "incognito": "split" is set in the manifest, per the docs: "True for content scripts running inside incognito tabs, and for extension pages running inside an incognito process. The latter only applies to extensions with 'split' incognito_behavior." Since we don't currently support that manifest property, I'd propose marking this RESOLVED FIXED. (I've verified that things look good for content scripts in https://github.com/callahad/webextension-tests/tree/master/incognito_context)
This no longer blocks Bug 1208765, as :evilpie noted, inIncognitoContext is not at full Chrome parity, but the manner in which RES uses it *is* supported.
Whiteboard: [extension]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: