The "tracking document" concept is used to ensure that the intersection
observer algorithm always runs at a time when rendering is up-to-date.
The tracking document provides the entry-point to running the
IntersectionObserver algorithm during UpdateAllLifecyclePhases.

Previously, if the observer had an explicit root element, then the
tracking document was the document containing the root; otherwise, the
tracking document was the execution context where the observer was
constructed. However, both of those are problematic:

- For the implicit root case, it's possible to construct an observer
in one window, and use it to observe a target in a different window
(via window.open()). When there are two top-level windows in a single
renderer process, their lifecycle updates run independently; so if
the algorithm runs during the tracking document's lifecycle update,
it's possible that the target element will not be rendering-clean.

- The explicit root case mostly works as intended, because the
algorithm only computes an intersection when root and target are in the
same document. However, there is a potential for subtle problems when a
target is moved to a different document. When that happens, the
observer may need to send a "not intersecting" notification; but
because the tracking document -- which determines when the algorithm
runs -- is associated with the root element's document, it's not
guaranteed that the algorithm will run (e.g., if the root's document
is suspended or detached from the frame tree; or if the root element is
also removed from its document).

These problems have been masked over until now because for a long time,
the lifecycle code would run the IntersectionObserver algorithm
indiscriminately on every frame. More recently,
SetNeedsIntersectionObserveration was added to LocalFrameView, to avoid
running the algorithm unnecessarily; however, that mechanism is currently
over-invalidating, so the algorithm still runs more than necessary.
Given that a single IntersectionObserver can have multiple targets in
multiple windows -- each of which runs its lifecycle updates
independently -- "tracking document" should be associated with the
IntersectionObservation, *not* the IntersectionObserver.
 

The "tracking document" concept is used to ensure that the intersection
observer algorithm always runs at a time when rendering is up-to-date.
The tracking document provides the entry-point to running the
IntersectionObserver algorithm during UpdateAllLifecyclePhases.

Currently, if the observer has an explicit root element, then the
tracking document is the document containing the root; otherwise, the
tracking document is the execution context where the observer is
constructed. However, both of those are problematic:

- For the implicit root case, it's possible to construct an observer
in one window, and use it to observe a target in a different window
(via window.open()). When there are two top-level windows in a single
renderer process, their lifecycle updates run independently; so if
the algorithm runs during the tracking document's lifecycle update,
it's possible that the target element will not be rendering-clean.

- The explicit root case mostly works as intended, because the
algorithm only computes an intersection when root and target are in the
same document. However, there is a potential for subtle problems when a
target is moved to a different document. When that happens, the
observer may need to send a "not intersecting" notification; but
because the tracking document -- which determines when the algorithm
runs -- is associated with the root element's document, it's not
guaranteed that the algorithm will run (e.g., if the root's document
is suspended or detached from the frame tree; or if the root element is
also removed from its document).

These problems have been masked over until now because for a long time,
the lifecycle code would run the IntersectionObserver algorithm
indiscriminately on every frame. More recently,
SetNeedsIntersectionObserveration was added to LocalFrameView, to avoid
running the algorithm unnecessarily; however, that mechanism is currently
over-invalidating, so the algorithm still runs more than necessary.
Given that a single IntersectionObserver can have multiple targets in
multiple windows -- each of which runs its lifecycle updates
independently -- "tracking document" should be associated with the
IntersectionObservation, *not* the IntersectionObserver.
 

The "tracking document" concept is used to ensure that the intersection
observer algorithm always runs at a time when rendering is up-to-date.
The tracking document provides the entry-point to running the
IntersectionObserver algorithm during UpdateAllLifecyclePhases.

Currently, if the observer has an explicit root element, then the
tracking document is the document containing the root; otherwise, the
tracking document is the execution context where the observer was
constructed. However, both of those are problematic:

- For the implicit root case, it's possible to construct an observer
in one window, and use it to observe a target in a different window
(via window.open()). When there are two top-level windows in a single
renderer process, their lifecycle updates run independently; so if
the algorithm runs during the tracking document's lifecycle update,
it's possible that the target element will not be rendering-clean.

- The explicit root case mostly works as intended, because the
algorithm only computes an intersection when root and target are in the
same document. However, there is a potential for subtle problems when a
target is moved to a different document. When that happens, the
observer may need to send a "not intersecting" notification; but
because the tracking document -- which determines when the algorithm
runs -- is associated with the root element's document, it's not
guaranteed that the algorithm will run (e.g., if the root's document
is suspended or detached from the frame tree; or if the root element is
also removed from its document).

These problems have been masked over until now because for a long time,
the lifecycle code would run the IntersectionObserver algorithm
indiscriminately on every frame. More recently,
SetNeedsIntersectionObserveration was added to LocalFrameView, to avoid
running the algorithm unnecessarily; however, that mechanism is currently
over-invalidating, so the algorithm still runs more than necessary.
Given that a single IntersectionObserver can have multiple targets in
multiple windows -- each of which runs its lifecycle updates
independently -- "tracking document" should be associated with the
IntersectionObservation, *not* the IntersectionObserver.