Compare Revisions

Compatibility with Legacy Addons

Change Revisions

Revision 642067:

Revision 642067 by billmccloskey on

Revision 642069:

Revision 642069 by billmccloskey on

Title:
Compatibility with Legacy Addons
Compatibility with Legacy Addons
Slug:
User:billmccloskey/e10s/Compatibility_with_Legacy_Addons
User:billmccloskey/e10s/Compatibility_with_Legacy_Addons
Content:

Revision 642067
Revision 642069
n10    <h3>n10    <h3 id="install.rdf_directive">
tt26    <h3>
27      Cross-process object wrappers (CPOWs)
28    </h3>
29    <p>
30      Here is a simple example of some add-on code that requires 
 >emulation to be compatible with electrolysis.
31    </p>
32    <pre>
33<code>content.document.documentElement.style = "border: 1px solid
 > red;";</code>
34</pre>
35    <p>
36      Add-ons in multiprocess Firefox run in the main process, so
 > they don't naturally have access to content documents. In order 
 >to make this code work, Firefox generates wrapper objects in the 
 >main process that look exactly like content objects. Each time an
 > add-on accesses a property on one of these wrappers, a message i
 >s sent synchronously to the content process to get or set the val
 >ue of the property. If the result of the property access is anoth
 >er content-process object, then Firefox generates a new wrapper f
 >or it (if one doesn't already exist). In the example above, wrapp
 >ers will be generated for:
37    </p>
38    <ul>
39      <li>
40        <code>content</code>: the Window object in the content pr
 >ocess
41      </li>
42      <li>
43        <code>content.document</code>: the content document
44      </li>
45      <li>
46        <code>content.document.documentElement</code>: the root D
 >OM element of the content tab
47      </li>
48    </ul>
49    <p>
50      Primitive JavaScript values like strings and integers do no
 >t have wrappers.
51    </p>
52    <p>
53      The use of cross-process wrappers (CPOWs) generates a lot o
 >f communications traffic between the main process and the content
 > process. We refer to this as inter-process communication (IPC) t
 >raffic. Let's consider the set of IPC messages that must be sent 
 >for the code above:
54    </p>
55    <ul>
56      <li>We'll assume that Firefox already has a wrapper availab
 >le for content. The wrapper has an ID; let's assume it's 0.
57      </li>
58      <li>Accessing the document property on the content wrapper 
 >sends a synchronous message to the content process. The result is
 > a document object that the main process must wrap. Let's assume 
 >this wrapper is given ID 1. The IPC message looks something like 
 >"get property document of object ID 0". The result is simply "obj
 >ect with ID 1". When the main process sees this result, it create
 >s a new wrapper for object ID 1, since it hasn't heard about it b
 >efore.
59      </li>
60      <li>Accessing the documentElement property on CPOW ID 1 sen
 >ds another message. In a similar fashion, it returns a new CPOW, 
 >with ID 2, that wraps the root DOM element.
61      </li>
62      <li>Setting the style property on CPOW ID 2 sends another m
 >essage. The message looks like "set the value of the style proper
 >ty of CPOW ID 2 to <code>'border: 1px solid red'</code>". Primiti
 >ve values like strings and integers are not wrapped with CPOWs li
 >ke objects are, so we send the value of the string in the IPC mes
 >sage.
63      </li>
64    </ul>
65    <p>
66      Sending messages between processes is fairly expensive, and
 > this simple fragment of code generated 4 messages. It should be 
 >clear that emulating single-process Firefox inside multiprocess F
 >irefox is not cheap.
67    </p>
68    <h4>
69      Bidirectional CPOWs
70    </h4>
71    <p>
72      In the example above, all of the wrappers lived in the main
 > process. However, it's possible to get CPOWs going in the other 
 >direction. What if, instead, we had done as follows?
73    </p>
74    <pre>
75<code>content.document.onload = function() { ... };</code>
76</pre>
77    <p>
78      The first message, to get the document, would be the same. 
 >The next message would have the form "set the onload property of 
 >CPOW ID 1 to ...". In this case, a property on an object in the c
 >ontent process is being set to a function in the main process. Un
 >like strings and integers, we can't send functions over the IPC c
 >hannel. Instead, we make a CPOW that goes in the other direction:
 > the wrapper lives in the content process and refers to an object
 > in the main process. To distinguish these different kinds of wra
 >ppers, we call them "up CPOWs" and "down CPOWs". A down CPOW poin
 >ts down, from the main process to the content process. An up CPOW
 > points up, from the content process to the main process. We also
 > need to give distinct IDs to these objects. An object that lives
 > in the main process will be given an idea like M1 and M2. An obj
 >ect in the content process will get an ID like C1 or C2. Let's re
 >do the example with that in mind:
79    </p>
80    <ul>
81      <li>We'll assume that Firefox already has a wrapper availab
 >le for content with ID C0.
82      </li>
83      <li>Accessing the document property on the content wrapper 
 >sends a synchronous message to the content process. The IPC messa
 >ge looks something like "get property document of C0". The result
 > is simply "C1". When the main process sees this result, it creat
 >es a new wrapper for C1 since it hasn't heard about it before.
84      </li>
85      <li>Setting the onload property on C1 sends another message
 >. The message looks like "set the value of the onload property of
 > C1 to M0".
86      </li>
87    </ul>
88    <p>
89      Note that the content process knows nothing about object M0
 >. However, when the document has finished loading, it can send a 
 >message to the parent asking it to call M0.
90    </p>

Back to History