1699810 - s/GetCrossDocParentFrame/GetCrossDocParentFrameInProcess/ in nsPresContext.cpp

Status: RESOLVED FIXED

(Core :: Layout, task)

Description

[Daniel Holbert [:dholbert]]

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 the callsite in nsPresContext.cpp.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: Bug 1699810: Use "InProcess" version of GetCrossDocParentFrame() in nsPresContext.cpp. r?tnikkel

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 callsite in nsPresContext.cpp is for some invalidation logic that we only
need to perform when the outer and inner document are part of the same display
list (i.e. part of the same process), as discussed in the adjacent
code-comment. It behaves just fine (doing nothing) if GetCrossDocParentFrame()
fails due to being in an out-of-process iframe.

Comment 2

[Timothy Nikkel (:tnikkel)]

So this bug reminds me that just auditing GetCrossDocParentFrame isn't enough: the underlying aspect of GetCrossDocParentFrame that causes the problem is using views to jump between documents. We need to audit all places that do that, so for example nsPresContext::GetParentPresContext is one.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0ef50e3ee466
Use "InProcess" version of GetCrossDocParentFrame() in nsPresContext.cpp. r=tnikkel

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

So this bug reminds me that just auditing GetCrossDocParentFrame isn't enough: the underlying aspect of GetCrossDocParentFrame that causes the problem is using views to jump between documents. We need to audit all places that do that, so for example nsPresContext::GetParentPresContext is one.

I filed bug 1699846 on auditing callers of nsPresContext::GetParentPresContext, to start.

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/0ef50e3ee466

Comment 6

[Timothy Nikkel (:tnikkel)]

(In reply to Daniel Holbert [:dholbert] from comment #4)

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

So this bug reminds me that just auditing GetCrossDocParentFrame isn't enough: the underlying aspect of GetCrossDocParentFrame that causes the problem is using views to jump between documents. We need to audit all places that do that, so for example nsPresContext::GetParentPresContext is one.

I filed bug 1699846 on auditing callers of nsPresContext::GetParentPresContext, to start.

Bug 1699902 for the rest.

Comment 7

[Chris Peterson [:cpeterson]]

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