32
edits
Project Fission/DocShell Tree Replace: Difference between revisions
Project Fission/DocShell Tree Replace (view source)
Revision as of 22:55, 15 October 2019
, 15 October 2019Updates.
(Format updates.) |
(Updates.) |
||
| Line 24: | Line 24: | ||
In pre-fission semantics, the prior tree would be entirely contained in a single process. Post-fission, this tree will be split across two processes, with three tree fragments across them: | In pre-fission semantics, the prior tree would be entirely contained in a single process. Post-fission, this tree will be split across two processes, with three tree fragments across them: | ||
1. A tree fragment (a.com -> a.com/foo) in process A | 1. A tree fragment (a.com -> a.com/foo) in process A | ||
2. A tree fragment (b.com/1 -> (b.com/2 | b.com/3)) in process B | 2. A tree fragment (b.com/1 -> (b.com/2 | b.com/3)) in process B | ||
3. A singleton tree fragment (a.com/bar) in process A | 3. A singleton tree fragment (a.com/bar) in process A | ||
The current usages of `nsIDocShellTreeItem` assume that DocShell trees are in-process. These usages need to be fixed, using various fission-related support infrastructure such as `BrowsingContext`s, `WindowContext`s, and `TabContext`s - or using IPC to remote processes where necessary. | The current usages of `nsIDocShellTreeItem` assume that DocShell trees are in-process. These usages need to be fixed, using various fission-related support infrastructure such as `BrowsingContext`s, `WindowContext`s, and `TabContext`s - or using IPC to remote processes where necessary. | ||
The usage of nsIDocShellTreeItem can be broken down into a few major categories. | The usage of nsIDocShellTreeItem can be broken down into a few major categories. | ||
== Usages of nsIDocShellTreeItem == | |||
=== Traverse of Tree Structure Only === | === Traverse of Tree Structure Only === | ||
| Line 40: | Line 42: | ||
As `BrowsingContext` is a cross-process, replicated tree, it fulfills expectations of having the full tree for a document within the querying process. | As `BrowsingContext` is a cross-process, replicated tree, it fulfills expectations of having the full tree for a document within the querying process. | ||
* TODO: Put link to simple traversal bugs here | |||
=== Existing valid uses === | === Existing valid uses === | ||
| Line 52: | Line 54: | ||
Some 20% of uses of nsIDocShellTreeItem access information held within DocShells, Documents, or Windows that may belong to ancestors or children in the tree. | Some 20% of uses of nsIDocShellTreeItem access information held within DocShells, Documents, or Windows that may belong to ancestors or children in the tree. | ||
*TODO: Add link to state-cache bugs | * TODO: Add link to state-cache bugs | ||
Fixing these uses depends on the kind of information being accessed. There are a few ways to break down the kinds of information accessed: | Fixing these uses depends on the kind of information being accessed. There are a few ways to break down the kinds of information accessed: | ||
| Line 68: | Line 70: | ||
This is similar to the first case, except that the information being accessed is not a specific existing field, but instead a characteristic that is synthesized from a number of different pieces of data within the internal structures. | This is similar to the first case, except that the information being accessed is not a specific existing field, but instead a characteristic that is synthesized from a number of different pieces of data within the internal structures. | ||
*TODO: Put example bug here | * TODO: Put example bug here (IsARIALive - scans documents in tree heirarchy for presence of accessibility flags) | ||
In these cases, a reasonable approach is to create a field in BrowsingContext or another context structure, which dynamically caches the synthesized information. Once again, an understanding of how often that particular synthesized state would need to be updated is relevant for this determination. | In these cases, a reasonable approach is to create a field in BrowsingContext or another context structure, which dynamically caches the synthesized information. Once again, an understanding of how often that particular synthesized state would need to be updated is relevant for this determination. | ||