Hello, Colleagues! tl;dr We're removing nsIDocShellTreeItem because of Fission. Please refrain from using it, and please help us out!
As we're getting further along with Fission, the work on removing nsIDocShellTreeItem completely comes into increased focus. With Fission enabled you can no longer rely on there being a complete nsDocShell tree in any content process since any given `nsDocShell` might be loaded in another process. This means that there are several endpoints from nsIDocShellTreeItem that just can't work the same way that they have before. Some quick examples are: nsIDocShellTreeItem.parent, because the parent nsDocShell is in another process. nsIDocShellTreeItem.rootTreeItem, because some nsDocShell between `this` and the root is in another process. nsIDocShellTreeItem.getChildAt, because the child nsDocShell at index is in another process. But there are many more! and it also has repercussions all over the place, e.g. nsDocShell::GetAllDocShellsInSubtree will be broken post-Fission, since it doesn't get all subtree nsDocShells. Here is where we need your help. We need everyone to stop adding code that uses nsIDocShellTreeItem, but also really anything that under the hood uses nsIDocShellTreeItem. We also need help removing existing uses of nsIDocShellTreeItem. Kannan has done awesome work to file and categorize all instances of where we need to work on nsIDocShellTreeItem[1], as well as reporting all discovered issues that we currently have[2]. The complexity of the changes needed to fix nsIDocShellTreeItem issues varies a lot. They range from quite simple, to tricky architectural changes. This is also something that Kannan has categorized[3]. An example of a simple change is bug 1585067[4]. Here the change consisted of switching from traversing on the nsDocShell tree to the BrowsingContext tree, replacing nsIDocShellTreeItem::GetSameTypeParent (or really nsIDocShellTreeItem::GetInProcessSameTypeParent, we've tried to rename obvious in-process culprits to make it clear that they suffer from only working in-process) with BrowsingContext::GetParent (and some other related checks like BrowsingContext::IsTopContent). An example of where we need to move a piece of nsDocShell state to BrowsingContext because it needs to be available in all synced BrowsingContext trees is bug 1587062[5]. This particular example happens to be for nsIDocShell, but the general procedure is the same. Here we move nsIDocShell.sandboxFlags to BrowsingContext.sandboxFlags. There seems to be a lot going on, but the gist of it is to move the attribute from nsIDocShell.idl to BrowsingContex.webidl and introducing a field declaration in BrowsingContextFieldList.h. A warning here is that we're in the middle of the process of changing this behavior as seen in bug 1583863[6]. What will be changing is that BrowsingContextFieldList.h is going away and fields will be declared in the BrowsingContext.h header. We're also making it less ergonomic to accidentally interact with a synced field in a non-synced way in order to improve synced field correctness. A hard example is bug 1575051[7], where we re-implemented nsDocShell::FindItemWithName in BrowsingContext. This is unfortunately not very representative for a hard nsIDocShellTreeItem bug, and that probably goes for all in the hard list. It's hard to say something general because they're ... hard :D If you're responsible for some piece of code, or if you want to chip in in general, feel free to reach out to us in the Fission team. We're on IRC in #domfission and on Slack on #fission. Cheers, Andreas [1] https://wiki.mozilla.org/Project_Fission/DocShell_Tree_Replace [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1467214 [3] https://wiki.mozilla.org/Project_Fission/DocShell_Tree_Replace#Usages_of_nsIDocShellTreeItem [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1585067 [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1587062 [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1583863 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1575051 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
