32
edits
Project Fission/DocShell Tree Replace: Difference between revisions
Jump to navigation
Jump to search
Project Fission/DocShell Tree Replace (view source)
Revision as of 21:06, 15 October 2019
, 15 October 2019Updates.
(Initial page.) |
(Updates.) |
||
| Line 9: | Line 9: | ||
In post-Fission semantics, this tree will no longer be completely in process for a given top-level document. Only contiguous fragments of the tree from the same origin are held in the same process: | In post-Fission semantics, this tree will no longer be completely in process for a given top-level document. Only contiguous fragments of the tree from the same origin are held in the same process: | ||
a.com | a.com | ||
| | | | ||
| Line 22: | Line 21: | ||
| | | | ||
a.com/bar | a.com/bar | ||
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: | ||
| Line 44: | Line 42: | ||
**TODO: Put link to simple traversal bugs here.** | **TODO: Put link to simple traversal bugs here.** | ||
== Existing valid uses == | === Existing valid uses === | ||
Existing uses of nsIDocShellTreeItem may be valid even in post-fission semantics. For example, some uses of nsIDocShellTreeItem may retrieve a same-origin parent, or null if the parent is not same-origin. | Existing uses of nsIDocShellTreeItem may be valid even in post-fission semantics. For example, some uses of nsIDocShellTreeItem may retrieve a same-origin parent, or null if the parent is not same-origin. | ||
In these cases, the post-Fission behaviour will be consistent with the program logic. I am not explicitly documenting these cases with bugs. | In these cases, the post-Fission behaviour will be consistent with the program logic. I am not explicitly documenting these cases with bugs. | ||
=== Deep Access of Document Data === | |||
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* | |||
Fixing these uses depends on the kind of information being accessed. There are a few ways to break down the kinds of information accessed: | |||
1. Existing state information that is not security sensitive | |||
These are fields, or flags held in Document, Window, DocShell, or other process-segregated structures, accessed via nsIDocShellTreeItem, which are not sensitive. | |||
Fixing these uses depends on how often the underlying data changes. If the data being accessed is infrequently updated, the state should be moved to BrowsingContext, WindowContext, or TabContext (as appropriate), and synchronized across processes. | |||
If this state is updated too frequently for it to be cross-process synchronized effectively, other options such as IPC must be considered. | |||
2. Synthesized state information that is not security sensitive | |||
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* | |||
example: 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. | |||
3. Access to security-sensitive information or complex information | |||
This class of uses relates to information which cannot easily be moved into BrowsingContext, TabContext or WindowContext. Sometimes this is because the information is security sensitive, and other time its because the query over DocShell/Document/Window is too complex to be represented as a simple synthesized state. | |||
These bugs tend to be difficult. Fortunately, many of these bugs relate to ongoing deep component work - including SessionHistory work, DOM Core work, etc. | |||