Implement WebExtensions API for private tabs

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
2 years ago
4 months ago

People

(Reporter: infocatcher.bugs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-denied] triaged, URL)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170316213829

Steps to reproduce:

I want to port Private Tab extension https://addons.mozilla.org/addon/private-tab/ into WebExtensions.


Actual results:

Currently there is no API around private tabs...


Expected results:

Should be API to open private tabs like
browser.tabs.create({
    …
    private: true
});
Or something from content script side.
(Reporter)

Updated

2 years ago
Component: Untriaged → WebExtensions: Compatibility
Product: Firefox → Toolkit

Comment 1

2 years ago
related to bug 1318388...
See Also: → bug 1318388
Whiteboard: [design-decision-needed] triaged

Comment 2

2 years ago
Please, can someone have a look at this bug?
Hi Dimas, this bug is flagged with [design-decision-needed], and the advisory board will likely look at it within a week or so.

Comment 4

2 years ago
When the "advisory board" discuss it, please consider that this extension is a feature unique to Firefox since Opera moved to Webkit/Blink, and one of reasons people have to use Firefox over alternatives.
(Reporter)

Comment 5

2 years ago
About API design, from https://github.com/Infocatcher/Private_Tab/issues/254#issuecomment-297237542:
https://github.com/mozilla/testpilot-containers/issues/47
> And possibly consider private-browsing as a container.

So, API for containers and ability to make private containers (or use built-in private mode container?) looks enough for our needs.
Hi infocatcher, this has been added to the agenda for the May 16 WebExtensions APIs Triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage

Agenda: https://docs.google.com/document/d/1vrhHNOelBty4hXcjQ8VbFk-azHRFFDVyGka7H0VpEa8/edit#
(Reporter)

Comment 7

a year ago
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #6)
> Hi infocatcher, this has been added to the agenda for the May 16
> WebExtensions APIs Triage meeting. Would you be able to join us? 

I'll try to join… Thanks.
Flags: needinfo?(amckay)

Comment 8

a year ago
We'll need some UX help on this one. We could do this through installation permissions, or maybe optional permissions, but there's a real concern that recording audio or video needs to give the user some kind of feedback that this is happening right now.

It would be pretty easy to install an add-on, approve this permission then forget about it.

Currently if a web page is doing audio or video capture, then it shows up on the tab. In this case there would be no tab to show an icon or indication to the user. This could be from a browser popup or a background page.

We'd need a firmer idea what to do for UX here before we approve this one, but we don't want to deny it either we think there's a good use case here.
Flags: needinfo?(amckay)

Updated

a year ago
Flags: needinfo?(mjaritz)

Comment 9

a year ago
Sorry comment 8 was meant for a completely different bug.

We'd be interested in the container team feedback on this one. Currently opening a new private tab in a non-private window is something Firefox doesn't support. Looking at the add-on mentioned in comment 0 it seems to do an awful lot of work.
Flags: needinfo?(mjaritz) → needinfo?(jkt)
Baku do you have any thoughts about this?

To me it probably is easy to implement, would private containers solve the same issue? (something else that has been requested).

It is also implementable by using containers and throwing them away at the end of the session too (minus tracking protection).

We also have the issue for clearing all storages from a container which would remove the need to deleting the container too.
Flags: needinfo?(jkt) → needinfo?(amarchesini)
> To me it probably is easy to implement, would private containers solve the
> same issue? (something else that has been requested).

I suggest to use a private container instead adding the private browsing feature per tab.
PrivateBrowsing code is still depending on the top-level window and, we could have unexpected regression if we just use OriginAttributes.mPrivateBrowsingId = 1 in a tab.

Before adding this feature at a WebExtension level, it's better to use the same feature somewhere in gecko.

> It is also implementable by using containers and throwing them away at the
> end of the session too (minus tracking protection).

Indeed this is what I would propose.
Flags: needinfo?(amarchesini)

Comment 12

a year ago
Based on the comments, I think going for the approach of using temporary containers is good here. The only real problem I see that containers aren't enabled by default and some settings (like tracking protection) aren't enabled on release and bug 1354602 is about that.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
Whiteboard: [design-decision-needed] triaged → [design-decision-denied] triaged

Comment 13

a year ago
I hope that this "WONTFIX" won't leave us users of the Private Tabs extension tab in a limbo.

>> It is also implementable by using containers and throwing them away at the end of the session too (minus tracking protection).

If by "session" you mean the full browsing session, and not just the tabs opened in that container, this isn't a replacement for the Private Tabs extension. 

With the extension, they are cleared as soon as we close the last private tab. This allows us to open a secondary Gmail account in a private tab, close it to clear the Google cookies, and then do a Google search in a new private tab in the same window in seconds, without affecting the other tabs. Having to close Firefox completely to clear the "temporary container" cookies would be worse than using a vanilla private window instead.

Something else I'm worried about is that Private Tabs lets us do things like search Twitter with this bookmark plus a keyword: private:https://twitter.com/search?f=tweets&q=%s . I have dozens of such bookmarks. 

Even if you implement temporary containers, will it be possible to set specific bookmarks and searches to open in them?  I don't want Twitter to always open in the temporary container, but only when I use that keyword or manually add private: before the URL.
(Reporter)

Comment 14

a year ago
(In reply to Andy McKay [:andym] from comment #12)
> Based on the comments, I think going for the approach of using temporary
> containers is good here. The only real problem I see that containers aren't
> enabled by default and some settings (like tracking protection) aren't
> enabled on release and bug 1354602 is about that.

This is only about containers as is, but what about private containers?
Will be the same "too hard to implement"?

Comment 15

a year ago
(In reply to Andy McKay [:andym] from comment #12)
> Based on the comments, I think going for the approach of using temporary
> containers is good here.

Will it be possible to make those containers behave as private tabs/windows?
In particular, will it be possible to..:
- to forbid storing the history?
- to forbid storing anything in the local storage?
- to forbid writing any caches to disk?
- to make login+password pairs used in a container not get prompted to be saved?

I need to know that now, because if anything of that is going to be forbidden - I see no reasons to keep firefox.
For me Firefox without Private Tabs is just another chrome and since chrome is better in other aspects - I'll just migrate to a real chrome.
Comment hidden (off-topic)

Updated

4 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.