845686 - Hook up GeckoContentController for nested content processes

Status: RESOLVED DUPLICATE of bug 1020199

(Core :: General, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

In this diagram (attachment 718845 [details]), we'll need APZCs associated with layer trees under the blue CPCompositorParent in the top-left of the diagram to be able to request repaints from their TabChilds associated with the red ContentChild in the bottom-right of the diagram.

Currently, the RenderFrameParent associated with the APZC lives in the same process as the APZC, so we can just bounce requests to it.  With nested content processes, that won't be the case anymore.

The simplest way to solve this is probably to create a second implementation of PRenderFrame that just bounces requests down the tree.  For example

  APZC ====> RenderFrameProxyParent               [b2g process]
             |
            \./
 RenderFrameProxyChild --> RenderFrameParent      [first-level process]
                             |
                            \./
                           TabChild               [nested process]

This will result in one extra IPC message per repaint request, which I suspect is fine since these are pretty infrequent (10 or so a second at most).  If it's not fine, we can create a bridge for these messages.

Comment 1

[Kartikaya Gupta (email:[e-mail])]

I think this is basically the same as bug 1020199, but perhaps based on a slightly older design of how the nested content processes worked out. Duping this over.