What fission is and why we do it: multi-process model of gecko change currently: each tab in own processes fission: each 'origin' within a tab has own process ie 1st party domain in one, iframes loading 3rd party things in another why? unclear if 1st-party domains in multiple tabs are same proc for security, helping sandbox untrusted code from ads, etc help mitigate spectre, meltdown, things of this nature better security through process boundary woop woop possibly better performance, but primarily security concerns driver here Architecture: cross-process Navigation DocumentChannel load starts in one proc, but we don't know where it will end (ie which content process loaded contnet needs to be run in) Session History thing that allows forward/back navigation global thing per tab currently lives in the content process fission: moved to parent process since so child content can access it (not landed yet) invisible change to consumers Remote WindowProxy needed for accessing 'windows' (like iframes) which now live in different procs should be an invisible change to consumers chrome code can no longer use 'x-ray vision' to change internal thingies Browsing Context and Window Context nsIDocShellTreeItem cannot be used post-fission world as things are corss-proc relevant methods renamed with 'InProcess' 'InChildAt' suffixes WindowContexts like BrowsingContext, but not persistent across navigation SyncedContext handles syncing of context state IPC Browsing Context Group 'closure' of all reachable browsing contexts list of all 'reachable' browsing contexts Syncing state: FIELD macro allows for syncing state between contexts, implication that it is SAFE to share data between contexts CanSet, DidSet methods can be overwridden If you do not implement CanSet, then procs will all have write access by default Do not add new state to nsDocShell determine if state needs to survive navigation if so use BrowsingContext if not use WindowContext Do not need to necessarily check principles everywhere if a browser context does not have a principle, that implies it is different from yours JS Window Actors registered in a few places (damn you fast slides) grep for JSWindowActorChild/JSWindowActorParent Window Actors only receive messages from their child/parent so don't need to namespace your messages (ie: Foo:FunMessage becomes FunMessage)

Schedule MVP start 2021 until then feature-based milestones M5 -> Nightly dogfoodable with fission M6 -> Enable for small % of Nightly users Contacts: Dev Lead: Nika Layzell nika@mozilla.com #fission channels on Slack and Matrix

Q&A: Will fission be mandatory when everything is finished? -> Short story Yes, Long story No We're not going to add a 'make my security worse' button to about:preferences for users Basically we can't expect process allocation model to be as described above on all platforms Android for instance has a cap on # of procs Also constrained platforms in terms of memory so lots of procs might suck Interesting fact, on android chromium isolates based on login credentials existing (ie if you have credentials for a site then it should be in its' own proc) tldr: don't write code with the assumption that the implmentation details are exaclty as described What are the potential perf benefits? Parellelism (duh) tldr; it's complicated (in ways you'd expect from talking about multi-process perf) so i won't go into every point in these notes, but it's *potentially* a win for some scenarios interestingly, switching tabs is faster as we only have to wait for the top-level content process to finish painting, so child iframes we don't have to wait to finish Question about security principles and some discussion about it: Don't spray principles around everywhere anymore The general assumption now for objects that if you don't have access to a thing, then you are not allowed to read/write it

To test fission: prefs: fission.autostart gfx.webrender.all

Links: docs: https://firefox-source-docs.mozilla.org/dom/Fission.html