Project Fission/DocShell Tree Replace: Difference between revisions

Fixing these uses depends on the kind of information being accessed.  There are a few ways to break down the kinds of information accessed:

These are fields, or flags held in Document, Window, DocShell, or other process-segregated structures, accessed via nsIDocShellTreeItem, which are not sensitive.

If this state is updated too frequently for it to be cross-process synchronized effectively, other options such as IPC must be considered.

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.

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.

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.