1630908 - [Fission] Consider OriginAttributes when selecting processes

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, enhancement, P2)

Description

[Paul Bone [:pbone]]

This is a feature idea/request. I'd like to know what others think.

Current behaviour:

I opened google.com/calendar in two tabs, one is in my "Personal" container and the other is in no container (the default container?). When I hover over their tabs I see the same PID on each of them. I have fission enabled.

Expected behaviour:

I should see different PIDs in their tabs. This may help with real isolation but it may also help users trust both fission and container tabs.

Comment 1

[Chris Peterson [:cpeterson]]

Nika agrees, though this bug doesn't need to block Fission MVP.

Comment 2

[Chris Peterson [:cpeterson]]

Correction: kmag says we need to fix this bug for private browsing tabs. We need to fix this for origins with different origin attributes in general, but private browsing is the most pressing reason.

Tracking for Fission Nightly milestone (M6)

Comment 3

[Neha Kochar [:neha]]

This will be complete when bug 1640939 gets done.

Comment 4

[Neha Kochar [:neha]]

Sorry, wrong dup'ing.

Comment 5

[Neha Kochar [:neha]]

Info from Nika for fixing this:

• We need to fix all callsites for getRemoteTypeForURI and getRemoteTypeForURIObject by passing in optional origin attributes (see https://searchfox.org/mozilla-central/rev/b4f3ce16c5099cf068fb023341959a0457adec9e/toolkit/modules/E10SUtils.jsm#235).
• We should probably filter out firstPartyDomain, isIsolatedMozBrowser, and partitionKey from OriginAttributes used for process selection (only include userContextId, privateBrowsingId, and geckoViewSessionConetxtId).
• We will need to audit all call-sites of related methods to make sure to pass in the correct OA values.

Comment 6

[Chris Peterson [:cpeterson]]

M7

Comment 7

[Anny Gakhokidze [:annyG]]

Nika, I am thinking of modifying the remote type to add OA at the end, so that our current remote type + selected values from OA are used as the key in our <remoteType: content process> map. Does this sound like a correct direction to you? I haven't figured out the exact details, but maybe new remote type could look something like this: webIsolated=https://example.com,pb=1, webIsolated=https://example.com,userContext=1 - I'll think more about this :)

I am currently auditing various callsites for getRemoteTypeForURI and getRemoteTypeForURIObject and trying to find a way to retrieve OA in each case. After that I might begin writing some test cases so I can better understand what kind of behaviour is expected and what kind of edge cases I have to address.

Comment 8

[Nika Layzell [:nika] (ni? for response)]

We shouldn't need to add a new way to attach the OA to the end of the origins, we already have a way to do it in how we define origins. Once you've changed callsites to getRemoteTypeForURI and getRemoteTypeForURIObject to accept originAttributes, we can replace the OAs here (https://searchfox.org/mozilla-central/rev/ff82c973f8ccb0475ec32439e9ec07014b3a681f/toolkit/modules/E10SUtils.jsm#227-231), with the ones passed in and it should work.

That will generate remote types like webIsolated=https://example.com^privateBrowsingId=1 or webIsolated=https://example.com^userContextId=5 :-)

Comment 9

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1630908 - Part 1: Pass OriginAttributes to be included with remote type, r=nika!

Comment 10

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1630908 - Part 2: Test that we include OriginAttributes in remoteType with Fission enabled, r=nika!

Depends on D101073

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/023a9d837f49
Part 1: Pass OriginAttributes to be included with remote type, r=nika,marionette-reviewers
https://hg.mozilla.org/integration/autoland/rev/5b747d5eaf90
Part 2: Test that we include OriginAttributes in remoteType with Fission enabled, r=nika

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/023a9d837f49
https://hg.mozilla.org/mozilla-central/rev/5b747d5eaf90

Comment 13

[Mel]

Heads up, possible breakage with this!
Latest nightly build from heftig's archlinux repo (https://pkgbuild.com/~heftig/repo/x86_64/) (firefox-nightly-86.0a1+20210120+h0478698744b1-1) dated on 20-Jan-2021 08:13 seems to break restoring websites from restore session when fission is enabled. I was working fine day before and according to https://mrotherguy.github.io/fx-nightly-changelog/changes/2021/01/2021-01-20.html there weren't many fission changes made to firefox.
The way breakage manifests itself is permanent loading symbol and no content being displayed. If the tab or pinned tab is closed and then undo close tab is selected, the tab does open and display itself.

Comment 14

[Neha Kochar [:neha]]

(In reply to Mel from comment #13)

Heads up, possible breakage with this!
Latest nightly build from heftig's archlinux repo (https://pkgbuild.com/~heftig/repo/x86_64/) (firefox-nightly-86.0a1+20210120+h0478698744b1-1) dated on 20-Jan-2021 08:13 seems to break restoring websites from restore session when fission is enabled. I was working fine day before and according to https://mrotherguy.github.io/fx-nightly-changelog/changes/2021/01/2021-01-20.html there weren't many fission changes made to firefox.
The way breakage manifests itself is permanent loading symbol and no content being displayed. If the tab or pinned tab is closed and then undo close tab is selected, the tab does open and display itself.

Thank you, Mel. This sounds like bug 1687616, which was found to be a regression from bug 1673683, which was backed out today.
Mel, would you be able to test tomorrow's nightly and see if this is still reproducible?

Comment 15

[Mel]

Mel, would you be able to test tomorrow's nightly and see if this is still reproducible?
Sure thing.

Comment 16

[Mel]

(In reply to Neha Kochar [:neha] from comment #14)

(In reply to Mel from comment #13)

Heads up, possible breakage with this!
Latest nightly build from heftig's archlinux repo (https://pkgbuild.com/~heftig/repo/x86_64/) (firefox-nightly-86.0a1+20210120+h0478698744b1-1) dated on 20-Jan-2021 08:13 seems to break restoring websites from restore session when fission is enabled. I was working fine day before and according to https://mrotherguy.github.io/fx-nightly-changelog/changes/2021/01/2021-01-20.html there weren't many fission changes made to firefox.
The way breakage manifests itself is permanent loading symbol and no content being displayed. If the tab or pinned tab is closed and then undo close tab is selected, the tab does open and display itself.

Thank you, Mel. This sounds like bug 1687616, which was found to be a regression from bug 1673683, which was backed out today.
Mel, would you be able to test tomorrow's nightly and see if this is still reproducible?

Confirming that it works fine with the latest build and fission enabled.