Jonathan Kingston [:jkt] he/him Reporter
	Description • 7 years ago

Currently our container assignment feature in Test pilot blocks web requests in the top frame and moves them into a container with a warning screen before it takes them to the page.

This actually has a few bugs:

1. Detecting page redirects is hard and often leaving short url pages open.
  - Assign Bugzilla to a container and use !bugzilla in DuckDuckGo.
2. Middle/Ctrl/Cmd click are not detectable so we focus the tab created as other  links should do this. https://github.com/mozilla/testpilot-containers/issues/442
3. This is actually pretty slow too, blocking and closing and reopen tabs etc

It would be cleaner if I could modify the following attributes of a web request as they happen:

1. URL
2. cookieStoreId

I'm implementation agnostic however it would be great if I could do something like:

webNavigation.onBeforeNavigate((details) => {
  return {
     url: `${extensionConfirmPage}?url=${url}`,
     cookieStoreId: "firefox-container-1"
  }
}, {}, ["blocking"]);

Rewriting URLs for navigations obviously is likely to be far more common use-case. I can't implement the "Never ask" feature we have without the cookieStoreId rewriting though.

The "Never ask" basically:
1. User clicks link on Google to Bugzilla
2. New tab opens in a different container

However we can't currently change container in the same tab which would require the API to create a new tab, it would then consider the normal rules in if the tab should be focused.

	Rob Wu [:robwu]
	Comment 1 • 7 years ago

Is this about navigations initiated from the awesomebar/location bar?

If not, and you are considering *any* top-level navigations, then there is the risk of leaking information between container tabs / cookie stores: A web page can open another page with some random unique identifier, and then correlate the different containers by the cookies and the URL.

The webNavigation API is currently purely an informational API, it does not block navigations.
The webRequest.onBeforeRequest API already support blocking responses (with promises too), so it might make sense to extend that API instead.

If this API is based on webRequests, then it is blocked on bug 1256122 (=redirects to moz-extension:-URLs are not functioning).

:jkt Can you clarify whether this request is foruser-triggered navigations only (awesomebar, maybe bookmarks?), or for any (top-level) web navigation?

	Jonathan Kingston [:jkt] he/him Reporter
	Comment 2 • 7 years ago

The request was for any navigation, as mentioned this could leak information through the URL. Cookies shouldn't be leaked across container boundaries. Referrer should also be able to be restricted and opener context shouldn't be preserved.

The reason I suggested webNavigation is because we shouldn't be permitting changing the cookie store within the same document (we could consider that later as it might be interesting for advert isolation however it might open up a huge can of worms).

We have a similar request somewhere to convert a tab into a new container, I believe this is less likely to cause leakage and issues.

	Caitlin Neiman [:caitmuenster]
	Comment 3 • 7 years ago

Hey Jonathan, this has been added to the agenda for July 25's triage meeting. Would you be able to join us? 

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

Agenda: https://docs.google.com/document/d/1BBIZhiHG1zlQiu6744jiAYyWJLa-B0iRu9vzWypkvF4/edit#

	Jonathan Kingston [:jkt] he/him Reporter
	Comment 4 • 7 years ago

Caitlin, this meeting actually colides with our new technical containers meeting but have moved to attend. As this is not a blocker for releasing containers I suspect we can make this a low priority. (I would like to release with this however I don't think it's likely before 57).

This bug actually is blocked by Bug 1323873 which is fairly technical.

Essentially once we have the ability to change a tabs cookie store on navigation this API is for exposing it to extension authors.
The containers extension implemented this by blocking web requests and changing the tab and closing other tabs, this however doesn't really lend itself to a bug free or clean experience.

This may actually be now possible to implement less buggy with WebNavigation.onCreatedNavigationTarget but it's still not going to be as clean as what I am proposing here.


Thanks
Jonathan