Currently ContainerState::ComputeOpaqueRect uses nsLayoutUtils::GetCrossDocParentFrame to walk up across document boundaries. It's not clear to me that we should try to maintain the related optimizations of calculating this area with regards to the opaque areas created by oop-iframes, but filing this for consideration.

We should only be worrying about window opaque regions for the parent process (where we can communicate with the actual OS widget), and it looks like that's what happens.

Given that, I don't think this matters, but we could probably make it clearer at this callsite that the results are only relevant/used in the parent process.

Where does the opaque region get communicated to the OS widget? It sounds like we should add an appropriate comment and then close this.

ContainerState::ComputeOpaqueRect calls nsDisplayListBuilder::AddWindowOpaqueRegion, which stores the region.

That is then used in ::IsItemAreaInWindowOpaqueRegion, which explicitly only looks at the value if we're in the chrome process.

It's also used in nsLayoutUtils::PaintFrame, where we grab the opaque region and call nsIWidget::UpdateOpaqueRegion. That function is implemented as a no-op for PuppetWidget, so won't do anything except in the chrome process.

Ryan, do you still plan to work on this?

No, I don't.

(In reply to Ryan Hunt [:rhunt] from comment #2)

Where does the opaque region get communicated to the OS widget? It sounds like we should add an appropriate comment and then close this.

If this bug is just about adding a comment and not about changing any code, then this bug doesn't need to block Fission.