1728332 - [Experiment] Pinned tabs of the same domain are initially loaded in separate Shared Web Content processes

Status: VERIFIED FIXED

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

Description

[Ciprian Muresan [:cmuresan], Ecosystem QA]

[Affected versions]:

• Firefox Nightly 93.0a1 - Build ID: 20210830162701

[Affected Platforms]:

• Windows 10
• macOS 10.15.7
• Linux MX 4.19

[Prerequisites]:

• Have the following prefs set on a new profile:
  • dom.ipc.processCount.webIsolated set to 4.
  • fission.autostart set to true.

[Steps to reproduce]:

1. Open 10 webpages from the same domain (eg. facebook, google, wikipedia) each in a new tab and pin all of them.
2. Open the about:processes page in a new tab.
3. Restart the browser using the Multiprocess Browser Console (ctrl/cmd+shift+j followed by ctrl/cmd+alt/option+r).
4. Observe the process list as the tabs are loading.

[Expected result]:

• The tabs with the same domain are split into 4 processes as they are loading.

[Actual result]:

• macOS & Linux: The tabs with the same domain are initially loaded in separate Shared Web Content processes before being split in 4 processes.
• Windows: All tabs are loaded in separate Shared Web Content processes and after all are loaded they transition to being split into 4 processes.

[Notes]:

• The issue is NOT reproducible if the tabs are loaded one at a time.
• The issue is NOT reproducible if the tabs are opened at the same time from a Bookmark folder or from the Synced Tabs sidebar.
• Attached a screen recording of the issue: link.

Comment 1

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Upon further investigation, it seems this behavior is present in the 2nd branch of the experiment (process-count-1) as well. Initially all tabs are loaded in Shared Web Content processes and then they are slowly migrated into a single process.

Comment 2

[Chris Peterson [:cpeterson]]

This bug will only affect users if we decide to increase the process count to greater than 1 process (bug 1727158), depending on the results of this experiment.

Comment 3

[Chris Peterson [:cpeterson]]

Tracking for Fission MVP.

Tentatively assigning to Nika because she knows the details of this bug.

Comment 4

[Chris Peterson [:cpeterson]]

We'd like to fix this bug soon, but it doesn't need to block Fission MVP.

Comment 5

[Jens Stutte [:jstutte]]

Hi Nika, I assume this is still a valid thing? Are you still planning to work on this? Thanks!

Comment 6

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

Yeah, I believe this is still valid though I haven't been actively working on it.

The rough sketch of the problem here is that the API which session restore uses to create new tabs doesn't know the URI that is going to be restored into each tab up-front, so when it is initially created it loads an initial about:blank which has a null principal and is allocated into one of the shared web content processes. Immediately after this load is complete, it then navigates to the actual webpage, which requires a process switch.

This specifically impacts pinned tabs because when the tab is being added, it is only considered to be added lazily if it is not pinned (https://searchfox.org/mozilla-central/rev/d4d7611ee4dd0003b492b865bc5988a4e6afc985/browser/base/content/tabbrowser.js#2986-2987), so the browser is added eagerly instead, and no URI is provided to addTrustedTab (https://searchfox.org/mozilla-central/rev/d4d7611ee4dd0003b492b865bc5988a4e6afc985/browser/base/content/tabbrowser.js#2989-2998). This can probably be handled by calculating the predicted remote type in this method & passing it to addTrustedTab as preferredRemoteType.

I threw together a quick patch for this which should work, but haven't tested it yet.

Comment 7

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

Attachment: Bug 1728332 - Part 1: Predict remote type when inserting restored tabs, r=gijs

This should mostly avoid the issue where newly created pinned tabs when
restoring a session are first created in the shared web process, and
migrated into the correct process upon navigating. I also added
remoteType prediction to the undoCloseTab and duplicateTab codepaths
to avoid unnecessary process changes there as well.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/30fa07c96caa
Predict remote type when inserting restored tabs, r=Gijs

Comment 9

[Cristian Tuns]

Backed out for causing mochitest failures on browser_tabs_in_urlbar.js

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_tabs_in_urlbar.js | Should have found all the tabs - 1 == 0 - JS frame :: chrome://mochitests/content/browser/browser/components/sessionstore/test/browser_tabs_in_urlbar.js :: test_unrestored_tabs_listed :: line 134

Comment 10

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

Attachment: Bug 1728332 - Part 2: Avoid raciness in sqlite interactions in browser_tabs_in_urlbar.js, r=adw

Before this change, there was raciness in this test due to the queries
to insert the opened tabs into the moz_openpages_temp table occuring at
the same time as the queries to read from that table in other
components. This patch makes the test initialize the DB connection
earlier, and ensure that no statements are still pending when running to
hopefully avoid potential races caused by the async nature of the
database connection.

Depends on D141146

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/675c85528602
Part 1: Predict remote type when inserting restored tabs, r=Gijs
https://hg.mozilla.org/integration/autoland/rev/4d74198886c2
Part 2: Avoid raciness in sqlite interactions in browser_tabs_in_urlbar.js, r=adw

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/675c85528602
https://hg.mozilla.org/mozilla-central/rev/4d74198886c2

Comment 13

[Ardelean Oana, Desktop QA [:oardelean]]

I managed to reproduce this issue following the STR from the Description on a 2021-08-31 Nightly build on Win10 64-bits. Confirmed as fixed on Firefox 100.0(20220428192727) and Nightly 101.0a1(20220501190841) on Win10 64-bits, Ubuntu 20.04 and macOS 10.15.