Per bug 1698680, we're adding a new wrapper-API called GetCrossDocParentFrameInProcess(), and we're migrating existing GetCrossDocParentFrame() calls to use the new function, after checking that they're OK with the fact that it doesn't cross processes for cross-origin content.

I'm filing this bug to convert some of the callers in nsIFrame.cpp.

(We'll probably convert all of the callers in nsIFrame.cpp eventually, but I'm just taking care of a handful that I'm most-sure about at the moment.)

This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)

We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.

This patch is focusing on some callsites where we've got a frame that needs a
repaint, and we're propagate that information up its ancestor chain. It's OK
for these notifications to stop when we hit the edge of of an out-of-process
iframe, because painting/compositing at that granularity is handled separately.

This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)

We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.

This patch fixes two callsites:

• The first callsite is an assertion whose condition becomes slightly stricter
  but should still be valid, in a scenario where we are at an oop-iframe
  boundary.

• The second is in IsFrameScrolledOutOfView(), which is part of an API that we
  use to optimize away animations if we can tell they're invisible (see calls
  to IsScrolledOutOfView() in KeyframeEffect.cpp). With fission, this API will
  be blocked from discovering whether an animated piece of content is in an
  iframe that's scrolled out of view in some cross-origin ancestor
  document. That's a little unfortunate from an optimization perspective, but
  it's OK from a correctness perspective, and it's probably desirable from a
  cross-origin information leakage perspective, too.

Depends on D108877

I'll jot down some thoughts about other GetCrossDocParentFrame callsites in nsIFrame.cpp that I'm not sure about yet (and am not converting yet).

First, there's one call in nsIFrame::GetOffsetToCrossDoc. This function aims to return a geometric offset between this and some other nsIFrame pointer. Initially I thought that this one would be trivially-fine, because obviously if we have two nsIFrame pointers, then the two nsIFrame objects must exist in the same process. But things could still conceivably fail; these nsIFrames could be in documents from the same origin that are separated by some out-of-process document, and therefore might not be able to reach each other. (E.g. we could have triply-nested subdocuments from origins A > B > A, or a document from origin B that has two subdocuments from origin A. If we can[1] somehow trigger this GetOffsetToCrossDoc API to compare the positions of nsIFrames in the two "A" documents in either of these scenarios, then we would probably end up failing (producing the wrong geometric offset), in a fission-enabled profile.)

[1] (I'm not sure if we actually could get ourselves into a situation where we'd call GetOffsetToCrossDoc in this way; I'm just speaking hypothetically.)

Yeah, that sounds very cumbersome. And it seems it depends on how the call sites gets the ancestor's nsIFrame pointer. For example this call site in ConvertToScreenRelativeVisual shouldn't cause the situation since the code tries to get the ancestor by walking up presContext tree, and the tree doesn't reach to the root one in such cases.

https://hg.mozilla.org/mozilla-central/rev/1f00650fb873
https://hg.mozilla.org/mozilla-central/rev/97fd6b8a9ac2

Setting Fission Milestone to M7a (the current Beta milestone) because this bug is blocking meta bug 1599913 which is a blocker for Fission M7a.