mozilla

Compare Revisions

Web Console remoting

Change Revisions

Revision 364721:

Revision 364721 by victorporof on

Revision 389231:

Revision 389231 by mihaisucan on

Title:
Web Console remoting
Web Console remoting
Slug:
Tools/Web_Console/remoting
Tools/Web_Console/remoting
Tags:
"Debugging", "web console"
"Debugging", "web console"
Content:

Revision 364721
Revision 389231
n34      Do note that we created only one Web Console actor for the n34      The new Web Console actors:
>general needs of the Web Console. The new actors: 
n38      </li>n
39      <li>The <code>WebConsoleObjectActor</code> allows us to mar
>shal content objects from the server to the client. 
n91      Notice that the <code>consoleActor</code> is also availablen89      Notice that the <code>consoleActor</code> is also available
> as a <strong>global actor</strong>. When you attach to the globa> as a <strong>global actor</strong>. When you attach to the globa
>l <code>consoleActor</code> you receive all of the network reques>l <code>consoleActor</code> you receive all of the network reques
>ts, page errors, and all of the other events from all of the tabs>ts, page errors, and all of the other events from all of the tabs
> and windows, including chrome errors and network events. This al> and windows, including chrome errors and network events. This ac
>lows us to implement a Global Console or to debug remote Firefox/>tor is used for the Browser Console implementation and for debugg
>B2G instances.>ing remote Firefox/B2G instances.
nn127    <h3>
128      Tab navigation
129    </h3>
130    <p>
131      To listen to the tab navigation events you also need to att
 >ach to the tab actor for the given tab. The <code>tabNavigated</c
 >ode> notification comes from tab actors.
132    </p>
n130      <p>n
131        If the client you work on needs to listen to the tab navi
>gation events, you also need to attach to the tab actor for the g 
>iven tab. The <code>tabNavigated</code> notification comes from t 
>ab actors. 
132      </p>
nn138    <p>
139      When page navigation starts the following packet is sent fr
 >om the tab actor:
140    </p>
141    <pre class="brush: js">
142<code class="brush: js">{
143  "from": tabActor,
144  "type": "tabNavigated",
145  "state": "start",
146  "url": newURL,
147  "nativeConsoleAPI": true
148}</code>
149</pre>
150    <p>
151      The <code>nativeConsoleAPI</code> property tells if the <co
 >de>window.console</code> object is native or not for the top leve
 >l window object for the given tab - this is always <code>true</co
 >de> when navigation starts. When navigation stops the following p
 >acket is sent:
152    </p>
153    <pre class="brush: js">
154<code>{
155  "from": tabActor,
156  "type": "tabNavigated",
157  "state": "stop",
158  "url": newURL,
159  "title": newTitle,
160  "nativeConsoleAPI": true|false
161}</code>
162</pre>
n232    <h2 id="The_WebConsoleObjectActor">n
233      The <code>WebConsoleObjectActor</code>
234    </h2>
235    <p>
236      The actor grip looks as follows, for two different objects:
237    </p>258    <p>
238    <pre class="brush:js;">259      We use the <code>ObjectActor</code> from dbg-script-actors.
 >js without a ThreadActor, to avoid slowing down the page scripts.
 > The debugger deoptimizes JavaScript execution in the target page
 >. The <a href="https://wiki.mozilla.org/Remote_Debugging_Protocol
 >#Grip_Lifetimes" title="https://wiki.mozilla.org/Remote_Debugging
 >_Protocol#Grip_Lifetimes">lifetime of object actors</a> in the We
 >b Console is different to the lifetime of these objects in the de
 >bugger - which is usually per pause or per thread. The Web Consol
 >e manages the lifetime of <code>ObjectActors</code> manually.
239{
240  "type": "object",
241  "className": "HTMLDivElement",
242  "displayString": "[object HTMLDivElement]",
243  "inspectable": true,
244  "actor": "conn0.consoleObj12"
245}
246{
247  "type": "object",
248  "className": "Object",
249  "displayString": "({a:1, b:2, c:3})",
250  "inspectable": true,
251  "actor": "conn0.consoleObj16"
252}
253</pre>
254    <p>260    </p>
255      The above packet is the minimal information we send to the 261    <div class="warning">
>web console, such that the object can be displayed in the output  
>and in the property panel. Unfortunately, we have some "weird" wa 
>ys on how we display objects - and these are different in the pro 
>perty panel. 
262      <p>
263        Prior to Firefox 23 we used a different actor (<code>WebC
 >onsoleObjectActor</code>) for working with JavaScript objects thr
 >ough the protocol. In <a href="https://bugzilla.mozilla.org/show_
 >bug.cgi?id=783499" title="https://bugzilla.mozilla.org/show_bug.c
 >gi?id=783499">bug 783499</a> we did a number of changes that allo
 >wed us to reuse the <code>ObjectActor</code> from the debugger.
256    </p>264      </p>
257    <p>
258      The <code>dislayString</code> property can also hold a <a h
>ref="https://wiki.mozilla.org/Remote_Debugging_Protocol#Objects"  
>title="https://wiki.mozilla.org/Remote_Debugging_Protocol#Objects 
>">LongStringActor grip</a> when the string is very long. 
259    </p>265    </div>
260    <p>
261      This is the <code>WebConsoleObjectActor</code> grip for fun
>ctions: 
262    </p>
263    <pre class="brush:js;">
264{
265  "type": "function",
266  "className": "function",
267  "displayString": "function myOnPaste(e)\n{\n  console.log(\"onp
>aste!\");\n}", 
268  "inspectable": false,
269  "functionName": "myOnPaste",
270  "functionArguments": [
271    "e"
272  ],
273  "actor": "conn0.consoleObj15"
274}
275</pre>
276    <p>
277      This object actor does not need the debugger API, nor does 
>it need the <code>ThreadActor</code>. It does not implement any o 
>f the request types from the debugger's <code>ObjectActor</code>  
>since they do not suit the needs of the Web Console client, excep 
>t the <code>release</code> request which releases the object acto 
>r. 
278    </p>
279    <h3 id="The_inspectProperties_request">
280      The <code>inspectProperties</code> request
281    </h3>
282    <p>
283      The Web Console object actor implements the <code>inspectPr
>operties</code> request type: 
284    </p>
285    <pre class="brush:js;">
286{
287  "to": "conn0.consoleObj17",
288  "type": "inspectProperties"
289}
290</pre>
291    <p>
292      Example reply:
293    </p>
294    <pre class="brush:js;">
295{
296  "from": "conn0.consoleObj17",
297  "properties": [
298    {
299      "name": "duron",
300      "configurable": true,
301      "enumerable": true,
302      "writable": true,
303      "value": {
304        "type": "object",
305        "className": "Object",
306        "displayString": "({opteron:\"amd\", athlon:\"amd\", core
>2duo:\"intel\", nehalem:\"intel\"})", 
307        "inspectable": true,
308        "actor": "conn0.consoleObj18"
309      }
310    },
311    {
312      "name": "foobar",
313      "configurable": true,
314      "enumerable": true,
315      "writable": true,
316      "value": "omg"
317    },
318    {
319      "name": "zuzu",
320      "configurable": true,
321      "enumerable": true,
322      "writable": true,
323      "value": "boom"
324    }
325  ]
326}
327</pre>
328    <p>
329      For each enumerable property on the object we send a proper
>ty descriptor. The <code>properties</code> array is sorted by pro 
>perty name. In each descriptor, for <code>set</code>, <code>get</ 
>code> and <code>value</code> we create object actors, if needed. 
330    </p>
n355        "displayString": "[object HTMLBodyElement]",n
356        "inspectable": true,
n361      {n
362        "type": "null"294      { "type": "null" },
363      },
364      {
365        "type": "undefined"295      { "type": "undefined" }
366      }
n372      Similar to how we send the page errors, here we send the acn301      Similar to how we send the page errors, here we send the ac
>tual console event received from the <code>nsIObserverService</co>tual console event received from the <code>nsIObserverService</co
>de>. We change the <code>arguments</code> array - we create <code>de>. We change the <code>arguments</code> array - we create <code
>>WebConsoleObjectActors</code> for each object passed as an argum>>ObjectActor</code> instances for each object passed as an argume
>ent - and, lastly, we remove some unneeded properties (like windo>nt - and, lastly, we remove some unneeded properties (like window
>w IDs). In the case of long strings, we use the <code>LongStringA> IDs). In the case of long strings we use the <code>LongStringAct
>ctor</code>. The Web Console can then inspect the arguments.>or</code>. The Web Console can then inspect the arguments.
n403    "displayString": "[object HTMLDocument]",n
404    "inspectable": true,
n421        <code>result</code> has the result object actor.n348        <code>result</code> has the result <code>ObjectActor</cod
 >e> instance.
n507}n434},
n513}n440},
441{
442  "from": "conn0.netEvent14",
443  "type": "networkEventUpdate",
444  "updateType": "requestPostData",
445  "dataSize": 1024,
446  "discardRequestBody": false
447},
n525}n459},
n531}n465},
n538}n472},
n544}n478},
n629        For all of the header and cookie values in the above packn563        Starting with Firefox 19: for all of the header and cooki
>ets we use <a href="https://wiki.mozilla.org/Remote_Debugging_Pro>e values in the above packets we use <a href="https://wiki.mozill
>tocol#Objects" title="https://wiki.mozilla.org/Remote_Debugging_P>a.org/Remote_Debugging_Protocol#Objects" title="https://wiki.mozi
>rotocol#Objects"><code>LongStringActor</code> grips</a> when the >lla.org/Remote_Debugging_Protocol#Objects"><code>LongStringActor<
>value is very long. This helps us avoid using too much of the net>/code> grips</a> when the value is very long. This helps us avoid
>work bandwidth.> using too much of the network bandwidth.
n668        For non-text response types we send the content in base64n602        Starting with Firefox 19: for non-text response types we 
> encoding (again, most-likely a <code>LongStringActor</code> grip>send the content in base64 encoding (again, most-likely a <code>L
>). To tell the difference just check if <code>response.content.en>ongStringActor</code> grip). To tell the difference just check if
>coding == "base64"</code>.> <code>response.content.encoding == "base64"</code>.
t705    <h2 id="The_locationChange_packet">t639    <h1>
706      The <code>locationChange</code> packet640      History
707    </h2>641    </h1>
708    <p>
709      The <code>locationChange</code> packets:
710    </p>642    <p>
711    <pre class="brush:js;">643      Protocol changes by Firefox version:
712{
713  "from": "conn0.console9",
714  "type": "locationChange",
715  "uri": "http://localhost/~mihai/mozilla/test.html",
716  "title": "",
717  "state": "start",
718  "nativeConsoleAPI": true
719}
720 
721{
722  "from": "conn0.console9",
723  "type": "locationChange",
724  "uri": "http://localhost/~mihai/mozilla/test.html",
725  "title": "foobar",
726  "state": "stop",
727  "nativeConsoleAPI": true
728}
729</pre>
730    <p>644    </p>
731      The <code>nativeConsoleAPI</code> API flag is included such645    <ol>
> that the user is correctly informed if the <code>window.console< 
>/code> API is overridden on the new page. 
646      <li>Firefox 18: initial version.
647      </li>
648      <li>Firefox 19: <a href="https://bugzilla.mozilla.org/show_
 >bug.cgi?id=787981" title="https://bugzilla.mozilla.org/show_bug.c
 >gi?id=787981">bug 787981</a> - added <code>LongStringActor</code>
 > usage in several places.
649      </li>
650      <li>Firefox 20: <a href="https://bugzilla.mozilla.org/show_
 >bug.cgi?id=792062" title="https://bugzilla.mozilla.org/show_bug.c
 >gi?id=792062">bug 792062</a> - removed <code>locationChanged</cod
 >e> packet and updated the <code>tabNavigated</code> packet for ta
 >b actors.
651      </li>
652      <li>Firefox 23: <a href="https://bugzilla.mozilla.org/show_
 >bug.cgi?id=783499" title="https://bugzilla.mozilla.org/show_bug.c
 >gi?id=783499">bug 783499</a> - removed the <code>WebConsoleObject
 >Actor</code>. Now the Web Console uses the JavaScript debugger AP
 >I and the <code>ObjectActor</code>.
653      </li>
732    </p>654    </ol>

Back to History