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). WindowContext 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 used. 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] [1] https://docs.google.com/presentation/d/1K4j6ngty64TZjJNS5qH-MBoOm3TI2dJedVsbH8jUhKE [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1614462 [3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-mozbrowser [4] https://chat.mozilla.org/#/room/#fission:mozilla.org [5] https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/docshell/base/nsILoadContext.idl#87 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
