Nested Content Processes: Difference between revisions

← Older edit

Nested Content Processes (view source)

Revision as of 07:20, 8 September 2015

4,045 bytes added , 8 September 2015

Add "On Tab destruction" into flow section

Chunmin

36

edits

@@ Line 10: / Line 10: @@
 == Terminology ==
-# '''Chrome Process''', '''Root Process''' or '''B2G Process''': The process with highest privilege which can access virtually all resources on the device. Many security and privacy sensitive API could only be performed by the chrome process. Content processes have to delegate the action to the chrome process through IPC.
+;Chrome Process, Root Process or B2G Process
-# '''Content Process''' or '''Child Process''': Processes with lower privilege. Almost all web apps and browser tabs run in this kind of process thus the name content process.
+: The process with highest privilege which can access virtually all resources on the device. Many security and privacy sensitive API could only be performed by the chrome process. Content processes have to delegate the action to the chrome process through IPC.
-# '''Grand Child Process''': The content processes whose parents are logically other content processes. In the OS's point of view, every content processes are still siblings.
+;Content Process or Child Process
-# '''IPC Protocol''': The protocol defines IPC messages sent between two threads or two processes. In code, a protocol class is usually named P<something>, see also [[IPC Protocols]].
+: Processes with lower privilege. Almost all web apps and browser tabs run in this kind of process thus the name content process.
-# '''Bridge''': Toplevel protocol usually connects the chrome process with content processes. A bridge protocol connects two content processes.
+;Grand Child Process
+: The content processes whose parents are logically other content processes. In the OS's point of view, every content processes are still siblings.
+;IPC Protocol
+: The protocol defines IPC messages sent between two threads or two processes. In code, a protocol class is usually named P<something>, see also [[IPC Protocols]].
+;Bridge
+: Toplevel protocol usually connects the chrome process with content processes. A bridge protocol connects two content processes.
 == Implementation ==
@@ Line 28: / Line 33: @@
 # Child process A ask chrome process to bridge to grand child process B via PContent::BridgeToChildProcess()
 # Child process A creates new PBrowser over PContentBridge::PBrowser
+=== GFX ===
+We will talk about how does layer composition work for nested processes.
+===== Terms =====
+;RenderFrameParent
+: Each TabParent has a RenderFrameParent which maintains the render state of the remote tab.
+;nsSubDocumentFrame
+: A frame is a layout unit in the frame construction phase. A nsSubDocumentFrame usually corresponding to a <iframe> and alike.
+;CompositorChild
+: The child counterpart of the PCompositor protocol. Each process could use a CompositorChild to communicate with the compositing process.
+;nsDisplayRemote
+: A DisplayItem is a command in the DisplayList that describes how to create a layer and draw into it. nsDisplayRemote knows how to build a RefLayer for remote frames.
+;RefLayer
+: A RefLayer is a anchor point for remote layer trees. It has a unique id for looking up the actual layer tree.
+===== Flow =====
+# On Tab creation
+## In TabChild::InitRenderingState() it creates the PRenderFrame using SendPRenderFrameConstructor and get a mLayersId back.
+##* If the TabParent/RenderFrameParent lives in the b2g process, use CompositorParent::AllocateLayerTreeId() to allocate layerId and register layerId via in process CompositorChild
+##* otherwise use ContentChild::GetSingleton()->SendAllocateLayerTreeId(aId) to allocate layerId and register layerId via OOP CompositorChild
+## Use the mLayersId to create a shadow layer manager. The shadow layer manager then could used to create layers.
+# On composition
+## On frame construction we create a nsSubDocumentFrame
+## If this nsSubDocumentFrame has a RenderFrameParent, then use it to create a nsDisplayRemote display item
+## On layer tree construction, nsDisplayRemote will create a RefLayer and bind the mLayersId of the RenderFrameParent to it.
+## When compositing the AsyncCompositionManager will WalkTheTree and resolve RefLayers using the mLayersId
+# On Tab destruction
+## nsFrameLoader::DestroyComplete() will be called in TabParent::ActorDestroy
+## Next, TabParent::Destroy() will be called in nsFrameLoader::DestroyComplete() and then TabParent::DestroyInternal() will be triggered
+## After finishing TabParent::DestroyInternal(), ContentParent::NotifyTabDestroying will be called.
+##* If TabParent is in chrome process, then its Manager() will be converted from nsIContentParent into ContentParent and pass its ContentParentId to ContentParent::NotifyTabDestroying
+##* Otherwise, if TabParent is in content process, then its Manager() will be converted from nsIContentParent into ContentBridgeParent and pass its ContentBridgeParentId to ContentParent::NotifyTabDestroying.
+## TabParent::Recv__delete__() will be called in case PBrowser::Msg___delete____ID of PBrowserParent::OnMessageReceived after PBrowserParent::SendDestroy() is called in TabParent::DestroyInternal()
+##* If TabParent is in chrome process, then its Manager() will be converted from nsIContentParent into ContentParent and pass its ContentParentId to ContentParent::DeallocateTabId. Next, ContentParent::NotifyTabDestroyed will be called.
+##* Otherwise, if TabParent is in content process
+### ContentBridgeParent::NotifyTabDestroyed() will be called first to check whether or not we should close the PContentBridge Channel. If the closed tab is the last one in its process, then the channel will be closed.
+### Next, its Manager() will be converted from nsIContentParent into ContentBridgeParent and pass its ContentBridgeParentId to ContentParent::DeallocateTabId. ContentParent::DeallocateTabId here will fire a IPC calling, ContentChild::SendDeallocateTabId, to request its parent process to deallocate the closed tab
+## After completing TabParent::Recv__delete__(), the closed tab will be removed from array mManagedPBrowserParent returned from ManagedPBrowserParent() in case PBrowserMsgStart of PContentBridgeParent::RemoveManagee
+## Finally, ContentBridgeParent::DeallocPBrowserParent will be fired
 === Security ===
@@ Line 51: / Line 101: @@
 TBD
+=== Work in progress ===
+<bugzilla>
+{
+"f1":"blocked",
+"o1":"anywords",
+"v1":"1020135"
+}
+</bugzilla>
+=== Get nested-oop passing all tests ===
+<bugzilla>
+{
+"f1":"blocked",
+"o1":"anywords",
+"v1":"1110650"
+}
+</bugzilla>