Hello Colleagues!

Now that we’ve passed All-Hands it’s time for another Fission
newsletter. To begin with the Fission team wants to thank all who came
to the introduction and the office hours! The slides from the
introduction are available online[1].

Our currently targeted milestones are M4.1, M5 and M6.

M4.1 contains Mochitests that we rolled over from M4 after we reached
our goal of 90% completion. We are currently halfway done, and the
remaining are targeted for March 2020. The total count of remaining
open bugs have dropped from 54 to 44 since the last newsletter. You
can follow the burndown at https://arewefissionyet.com/m4/. The
remaining issues are spread out over 15+ components, so just a
reminder: component owners, not the DOM Fission team, are responsible
for making their component’s tests Fission-compatible!

M5 is also in progress with an ETA of March 2020, after which we
expect to be able to ask you all to join in and help us out with
dogfooding Fission. The ratio between opened and total bugs has
progressed from 56% (123/218 bugs) to 73% (167/227 bugs). The burndown
of M5 is at https://arewefissionyet.com/m5/.

M6 is our Fission feature complete milestone when we are ready to
enable Fission by default in Nightly (starting with some A/B
experiments of stability and performance).


Since the last newsletter we’ve managed to land WindowContext, a
synced context similar to BrowsingContext but with a different scope
and life-cycle. The major difference being that BrowsingContexts
survive across navigations (in the general case, not considering COOP
e.g.) but WindowContexts do not. The same relationship can be seen in
nsDocShell - Document, and nsGlobalWindowOuter - nsGlobalWindowInner.
With WindowContext we get a way to keep track of the context tied to
the document across content processes in the same way that
BrowsingContext allowed us to keep track of the context tied to
document shells across content processes.

How to check if Fission is enabled

One thing that we thought we’d bring up is how code can check if
Fission is enabled if you’re adding Fission compatibility that you
expect not to be turned on until Fission ships. The key thing to take
away is that you should not read the pref (“fission.autostart”, which
is used to start content processes with Fission enabled)! Instead you
should check if the load context uses remote sub-frames. Non-Fission
tabs may exist, even if the “fission.autostart” global pref is true.

In tests SpecialPowers.useRemoteSubframes[5] can be used to check if
Fission is enabled from a mochitest. In browser mochitests, use
gFissionBrowser. Otherwise you want to check the load context found on
the docshell, which also has a check for if remote subframes should be

We’re removing <iframe mozbrowser>[2,3]

This is in its initial phase, but is still cause for celebration!

How to reach the Fission team

As always you can find us at #fission in Slack and on Fission in Riot[4]

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1614462
[4] https://chat.mozilla.org/#/room/#fission:mozilla.org
dev-platform mailing list

Reply via email to