It's been two months since the last newsletter and there have been quite
some accomplishments for Fission.
Fission Milestones M4, M4.1 and M5
Fission M4 milestone aimed to get Mochitests running and successfully
passing with Fission enabled. https://arewefissionyet.com/m4/?original
shows the fantastic progress that has been made on this goal. We
completed our M4 milestone by successfully getting 90% of Mochitests to
pass with Fission enabled, in just about a quarter.
The remaining tests to be fixed by the core Fission team are at a low
enough point that we started working towards the next milestone too.
This milestone was made possible because of the support we received from
all Firefox teams. The remaining test failures have been moved to an
additional milestone (M4.1), so that the teams responsible for those
tests continue the drive towards 100% Fission coverage on Mochitests.
https://arewefissionyet.com/m4/ shows the burndown graph for M4.1. Some
failing tests depend on WindowContext (under construction) and have been
identified as such and are not covered in M4/M4.1. To help us get to
100%, take a look at the spreadsheet
(https://docs.google.com/spreadsheets/d/1kjp32JTuB4axM3wKx0iIYL2Ado-HcyeBhoY-siGxYAs/)†
that tracks the failures and help out where you can.
With M4 done and the remaining Mochitest fixing moved to M4.1, we’re
also shifting the focus of the core Fission team to the M5 milestone.
The goal of M5 is to make Fission-enabled builds be usable by developers
and testers for dogfooding. We’ll be focusing on crashes and broken
major functionality.
†: mozilla-internal document, public read-only mirror
<https://docs.google.com/spreadsheets/d/e/2PACX-1vRRmnRUOy-KDDScK8o8Z6aKRaEtXKXb39Yn2OOPXoMgZwcMC3Oce3jgSjI5-jRK0jLS73gQYLkfSTJ_/pubhtml?gid=1560718888&single=true>
also available.
DocumentChannel
With Fission, the process that initiates a URI load might not be the
same as the one that needs to display the content. Even worse, we
frequently don’t know what the final process will be until we’ve
finished navigating any HTTP redirects.
To solve this, the originating docshell will now create a
DocumentChannel, a protocol-agnostic placeholder channel, rather than a
real network channel. DocumentChannel proxies the request into the
parent process, where we can wait for all redirects and then make the
right decision about where to deliver the final content. This lets us
move a lot of logic for how to target a load out of the originating
docshell, and into the parent process.
DocumentChannel is now enabled on Nightly for all protocols, with the
Fission-specific process selection code disabled. We’re currently
working to support handling content that needs to be downloaded directly
in the parent.
Parent process owning Session History
Session History is the part of a web engine that supports functions like
the back/forward buttons, the History menu item, etc. It contains the
state information about the pages that were loaded in a particular
window/tab, such as the active scroll position, filled-in form data, and
more. In Gecko, the state is currently stored in the child processes
where those pages were loaded. With Fission, we're changing the
processes in which pages are loaded, so we need to also re-architect how
Session History works.
During a browsing session, the user could have navigated to different
origins within the same tab, and so the tab’s session history data might
apply to pages loaded in different processes. At any given point in
time, a page can also contain iframes with data from different origins,
which in turn implies session history contains data for all the
corresponding processes. In order to not leak cross-origin data, we need
to move the session history data to the parent process. We've landed
(behind a pref) a major piece of this re-architecting work in M4 that
moves most of the session history data to the parent process, while
keeping the same underlying API. Because the existing APIs allowed
synchronous access to the data, we're now using synchronous IPC messages
to get or set the data in the parent process. The next step for this
project is to remove the synchronous IPC messages and will require a new
set of APIs which are currently being designed.
- The Fission Team.
Previous newsletters:
#1
<https://groups.google.com/d/msg/mozilla.dev.platform/Y_vliuQ_7F0/HOXTc7JYBgAJ>
#2
<https://groups.google.com/d/msg/mozilla.dev.platform/sevpJDQwDfg/qlFrsS7uAAAJ>
#3
<https://groups.google.com/d/msg/mozilla.dev.platform/-jKocw2bAlw/RLuD9MA9DAAJ>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
