Open Bug 1728331 Opened 3 months ago Updated 2 months ago

[Experiment] [process-count-4] Same domain tabs are loaded in the same process when reloaded in bulk


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




Fission Milestone Future
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox91 --- disabled
firefox92 --- wontfix
firefox93 --- fix-optional
firefox94 --- fix-optional


(Reporter: cmuresan, Assigned: nika)



[Affected versions]:

  • Firefox Nightly 93.0a1 - Build ID: 20210830162701

[Affected Platforms]:

  • Windows 10
  • macOS 10.15.7
  • Linux MX 4.19


  • 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.
  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. Right click the about:processes tab and choose the "Select all Tabs" option.
  5. Right click the same tab and select the "Reload Tabs" option.
  6. Wait for all tabs to load and observe the process list.

[Expected result]:

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

[Actual result]:

  • The tabs with the same domain are all in the same process.


  • The issue is also reproducible when selecting multiple tabs and reloading them simultaneously, but in this case they can end up in two processes.
  • The issue is also reproducible if the tabs are unloaded via Session Restore.
  • 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.

Took a second to look into this. I believe this is caused because we always choose not to create a new process for a remote type if an existing process doesn't have any tabs loaded in it. This is done here: With normal tab opening we would create the browser in each new process synchronously, due to the blocking process launch, but for navigation process switches with Fission, we create it async, and there's a short time period during the process switch where we have the new process launched, but it doesn't have any tabs technically loaded in it yet. During this time if we do another process switching navigation, we'll end up re-using the same process, as we don't see the process as having any tabs loaded in it.

If we want to avoid this behaviour, we'll need to track pending navigations into a content process in addition to existing tabs, and handle them here.

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.

Blocks: 1727158
See Also: → 1728332

Tracking for Fission MVP.

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

Assignee: nobody → nika
Fission Milestone: ? → MVP
Priority: -- → P3
Whiteboard: fission-soft-blocker

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

Fission Milestone: MVP → Future
Whiteboard: fission-soft-blocker

The changes I currently have posted in bug 1731792 should also fix this issue.

You need to log in before you can comment on or make changes to this bug.