Per bug 1698680, we've added 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 on doing this for changes in ViewportFrame.cpp

Similar to bug 1698987: this particular call is about propagating the NS_FRAME_IN_POPUP state bit from parent-frames to child frames (for popups like menulist-dropdowns). It seems unlikely that we'll have a mix of content from different origins/processes within a single dropdown menu, so I think it's OK for this propagation to be explicitly same-process.

This patch doesn't change behavior. The "InProcess" version of this API (which
we're migrating to in this patch) is used to annotate GetCrossDocParentFrame()
callsites that have been vetted as being OK with the fact that this API returns
null at the boundary of a cross-origin iframe, if fission is enabled.

The call that's being migrated here is about propagating the NS_FRAME_IN_POPUP
state-bit into subframes that are nested inside of a popup. This state bit is
used to mark things like the menulist-dropdown popup. It's unlikely that we'll
host cross-origin content in iframes inside of popups (and if we do, it's
unlikely that it'll need to care about copying this bit across process/origin
boundaries into said popup). So it seems reasonable to consider this an
"InProcess" call and to have it be OK with failing to propagate in the event
that it were to encounter an OOP-iframe boundary.

Minor status update: tnikkel brought up a possible issue in his review in phabricator, which requires a bit of research and testing [1] to find out if this patch is sound as-it-stands or not.

In the meantime, I don't think this really needs to block M7a, so I'm adjusting this to M8.

[1] (possibly writing a test add-on that does a particular combination of things, which I need to find time to learn how to do properly, and then see if I can make it fail in interesting ways)

This bug is a soft blocker for Fission M8. We'd like to fix it before our M8 Release experiment, but we won't delay the experiment waiting for it.

Moving from Fission M8 to Future since comment 0 says we're unlikely to have a mix of content from different origins/processes within a single dropdown menu.

If you think this bug should block shipping Fission MVP, just let me know.

https://hg.mozilla.org/mozilla-central/rev/15ab4f640c68

Since this patch doesn't change behavior, we don't need to uplift it to Beta 92. Setting status-firefox92=wontfix.