Hook up GeckoContentController for nested content processes

RESOLVED DUPLICATE of bug 1020199

Status

()

Core
General
RESOLVED DUPLICATE of bug 1020199
5 years ago
4 years ago

People

(Reporter: cjones, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

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.
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1020199
You need to log in before you can comment on or make changes to this bug.