850019 - Hooking up devtools, profiler to metro

Status: RESOLVED FIXED

(Tracking Graveyard :: Metro Operations, defect)

Description

[Allison Naaktgeboren :ally]

This would involve working with devtools to hook up a profiler so we can see what is going on with performance (Im especially interested in our chrome performance)

Asa, can we get a story for this, and then this can morph into the work bug?

Comment 1

[Allison Naaktgeboren :ally]

Can we either get a story for this one, or add it to the story for testing

Comment 2

[Jim Mathies [:jimm]]

https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

Getting this running on b2g looks pretty painful, maybe we could improve on that. I guess the core issue would be getting the functionality in the desktop extension hooked up somehow.

We could certainly use this in our omtc work.

Comment 3

[Brian R. Bondy [:bbondy]]

I'm going to temporarily move this to v2. If we find some jank we want to diagnose though it can move back under that story.

Comment 4

[Brian R. Bondy [:bbondy]]

oops thanks for catching that.

Comment 5

[Asa Dotzler [:asa]]

Agreed, v2 unless we find ourselves unable to diagnose some issue that can only be managed by wiring this up.

Comment 6

[Allison Naaktgeboren :ally]

as discussed in teammeetup to help us focus on perf on low end devices.

Comment 7

[Marco Mucci [:MarcoM]]

Moving to Planning Backlog to be included in V1.

Comment 8

[Allison Naaktgeboren :ally]

For clarity of our devtools friends, on windows 8 the metrofx and the desktop fx are installed together, and are running on the same machine (I usually run with one on each monitor). The metrofx may be run in two ways, in the metro immersive environment, and in a simulated form of that on the classic desktop.

classic = aurora fx in windows desktop mode
metro =  my local m-c build of metrofx w/ harthur's devtools patch applied running in the immersive metro mode (1 app only, no popups, but there are modal dialogs)
-metrodesktop = my local m-c build of metrofx in -metrodesktop mode with harthur's patch applied. This runs on the classic desktop but has a different widget backend. This is the mode that allows use to monkeypatch in the dom inspector

prefs on all 3 forms of firefox:
classic
devtools.debugger.chrome-enabled = true
devtools.debugger.chrome-debugging-host = localhost
devtools.debugger.chrome-debugging-port = 6080
devtools.debugger.enabled = true
devtools.debugger.force-local = true
devtools.debugger.log = true
devtools.debugger.remote-enabled = true
devtools.debugger.remote-autoconnect = false
devtools.debugger.remote-host = localhost
devtools.debugger.remote-port = 6000

metro
(devtools.debuger.* has only the following 4 prefs)
devtools.debugger.force-local = false
devtools.debugger.remote-enabled = true
devtools.debugger.remote-port = 6000
devtools.debugger.log = true

-metrodesktop
(devtools.debuger.* has only the following 4 prefs)
devtools.debugger.force-local = false
devtools.debugger.log = true
devtools.debugger.remote-enabled = true
devtools.debugger.remote-port = 6000

1-set settings on classic

2-set settings on metro (or -metrodesktop. The behavior&errors are the same)

3-tools menu -> web developer -> connect
  loads chrome://browser/content/devtools/connect.xhtml
  host: localhost
  port: 6000

4- click connect

5- on metro, click accept on the incoming connection modal dialog
The following errors crop up on the jsconsole:
Timestamp: 5/21/2013 3:16:10 PM
Error: Handler function DebuggerTransport.prototype.onStopRequest threw an exception: TypeError: this.getTabContainer(...) is undefined
Call stack:
BRA_unwatchWindow@chrome://global/content/devtools/dbg-browser-actors.js:187
BRA_disconnect@chrome://global/content/devtools/dbg-browser-actors.js:68
AP_cleanup@chrome://global/content/devtools/dbg-server.js:489
DSC_onClosed@chrome://global/content/devtools/dbg-server.js:693
DT_onStopRequest@chrome://global/content/devtools/dbg-transport.js:176
@chrome://global/content/devtools/dbg-transport.js:41
Source File: chrome://global/content/devtools/dbg-transport.js
Line: 60

Timestamp: 5/21/2013 3:16:29 PM
Error: TypeError: this.getTabContainer(...) is undefined
BRA_watchWindow@chrome://global/content/devtools/dbg-browser-actors.js:178
BRA_onListTabs@chrome://global/content/devtools/dbg-browser-actors.js:105
DSC_onPacket@chrome://global/content/devtools/dbg-server.js:649
DT__processIncoming/<@chrome://global/content/devtools/dbg-transport.js:227
@chrome://global/content/devtools/dbg-transport.js:41
Source File: chrome://global/content/devtools/dbg-server.js
Line: 602

6- The classic is stuck in a spinning throbber, "Connecting..."
The jsconsole spits out
Timestamp: 5/21/2013 2:44:33 PM
Error: Server did not specify an actor, dropping packet: {"error":"unknownError","message":"error occurred while processing 'listTabs': TypeError: this.getTabContainer(...) is undefined\nBRA_watchWindow@chrome://global/content/devtools/dbg-browser-actors.js:178\nBRA_onListTabs@chrome://global/content/devtools/dbg-browser-actors.js:105\nDSC_onPacket@chrome://global/content/devtools/dbg-server.js:649\nDT__processIncoming/<@chrome://global/content/devtools/dbg-transport.js:227\n@chrome://global/content/devtools/dbg-transport.js:41\n"}
Source File: resource://gre/modules/devtools/dbg-client.jsm
Line: 587

7- They never connect

Other Notes:
-I get the same behavior if I try to connect to metro or -metrodesktop
-When Heather & Nick patiently walked me through this the first time, we able to get the metro & the classic to connect, but classic said there was no data to connect to and metro spit out an error about actors.js being undefined. I am unable to reproduce that part now.

Comment 9

[Panos Astithas (he/him) [:past] (please ni?)]

You will need to provide a metro-specific override of the browser actors (formerly dbg-browser-actors.js, as of a few minutes ago webbrowser.js). The error message you are hitting points to a missing getBrowser() method on your window, presumably because you don't use a XUL window?

See for example how Fennec implements the getTabContainer() method in their version of the browser actors:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/dbg-browser-actors.js#110

Bug 870081 and its dependencies will simplify this process, providing a cleaner API to base your work on.

Comment 10

[Allison Naaktgeboren :ally]

Attachment: patch courtesy of harthur

Comment 11

[Marco Mucci [:MarcoM]]

Hi Ally, can you provide a point estimate for this feature story.

Comment 12

[Allison Naaktgeboren :ally]

p=13. It's uncharted territory with a brand new api

Comment 13

[Allison Naaktgeboren :ally]

Attachment: current error message on both sides of the connection

Comment 14

[Allison Naaktgeboren :ally]

Attachment: nonworking patch, empty function bodies

the function bodies on this patch are empty as I try(and fail) to demonstrate that the override code works. This code is modeled from http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/dbg-browser-actors.js#110, the error messages are in the other attachment.

Comment 15

[Allison Naaktgeboren :ally]

(6:30:45 PM) mbrubeck: ally: gBrowser is a Firefox thing; I think it points to the <tabbrowser> widget, which we don't use
(6:31:20 PM) mbrubeck: We'll either need to fake up a gBrowser that implements the methods/properties that devtools needs, or modify their code not to depend on gBrowser

Comment 16

[Allison Naaktgeboren :ally]

Attachment: connects, tabs ok, profiler page blank

- The debug server starts & connects. We get list of tabs, the console, the debugger, and the network tools.

yay!

The profiler though, shows start & stop buttons, but no actual data is displayed 

The desktop when attached to metro occasionally spits out the following, which may be relevant

sometime when messing with the settings, desktop spat the following otu
Timestamp: 6/14/2013 2:38:37 PM
Error: TypeError: this._debuggee is undefined: @resource://app/modules/devtools/StyleEditorPanel.jsm:118
EventEmitter_emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/shared/event-emitter.js:107
TabTarget.prototype.destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/target.js:388
TBOX_destroy@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox.js:718
EventEmitter_emit@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/shared/event-emitter.js:107
WindowHost.prototype._boundUnload@resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/framework/toolbox-hosts.js:243

Source File: resource://gre/modules/commonjs/toolkit/loader.js -> resource:///modules/devtools/shared/event-emitter.js
Line: 112

Comment 17

[Panos Astithas (he/him) [:past] (please ni?)]

That error happens when the style editor is being destroyed, so if it seems to work fine in normal use there may be a race in our shutdown path somewhere.

A protocol dump would be very useful to determine what is going on with the profiler and the other actors.

Comment 18

[Panos Astithas (he/him) [:past] (please ni?)]

Comment on attachment 762999 [details] [diff] [review]
connects, tabs ok, profiler page blank

Review of attachment 762999 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/devtools/client/dbg-client.jsm
@@ +530,4 @@
>     *        debugging server responds.
>     */
>    request: function DC_request(aRequest, aOnResponse) {
> +    Cu.reportError("request(): "+ JSON.stringify(aRequest)); //anaaktge debug

You shouldn't need this if you enable the devtools.debugger.log pref, since it produces large swaths of debug output in the terminal. If terminal and metro don't get along well, you could change dumpn() in toolkit/devtools/server/main.js to use Cu.reportError instead.

Comment 19

[Allison Naaktgeboren :ally]

The metro-side work has been finished off. Unassigning myself.