1358058 - Implement WebExtensions API for private tabs

Status: RESOLVED WONTFIX

(WebExtensions :: Compatibility, enhancement)

Description

[Infocatcher]

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.

Comment 1

[:shell escalante]

related to bug 1318388...

Comment 2

[Dimas]

Please, can someone have a look at this bug?

Comment 3

[Tomislav Jovanovic :zombie]

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

[08xjcec48]

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.

Comment 5

[Infocatcher]

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.

Comment 6

[Caitlin Neiman [:caitmuenster]]

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#

Comment 7

[Infocatcher]

(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.

Comment 8

[Andy McKay]

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.

Comment 9

[Andy McKay]

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.

Comment 10

[Jonathan Kingston [:jkt] he/him]

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.

Comment 11

[Andrea Marchesini [:baku]]

> 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.

Comment 12

[Andy McKay]

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.

Comment 13

[08xjcec48]

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.

Comment 14

[Infocatcher]

(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

[Sym Cek]

(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 16

[Otto J. Mäkelä]

(In reply to Sym Cek from comment #15)
> 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.

It seems Chrome (or Chromium) it is. Too bad.