Closed Bug 850019 Opened 8 years ago Closed 7 years ago

Hooking up devtools, profiler to metro

Categories

(Tracking Graveyard :: Metro Operations, defect)

x86_64
Windows 8
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ally, Unassigned)

References

Details

(Whiteboard: [waiting on devtools] [story])

Attachments

(2 files, 2 obsolete files)

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?
Can we either get a story for this one, or add it to the story for testing
Flags: needinfo?(asa)
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.
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.
Blocks: metrov1it2
No longer blocks: metrov1triage
Blocks: metrov2planning
No longer blocks: metrov1it2
oops thanks for catching that.
Agreed, v2 unless we find ourselves unable to diagnose some issue that can only be managed by wiring this up.
Flags: needinfo?(asa)
Whiteboard: [metro-mvp?]
as discussed in teammeetup to help us focus on perf on low end devices.
Flags: needinfo?(mmucci)
Moving to Planning Backlog to be included in V1.
Blocks: metrov1planning
No longer blocks: metrov2planning
Flags: needinfo?(mmucci)
Assignee: nobody → ally
Summary: Hooking up a profiler to metro → Hooking up devtools, profiler to metro
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.
Blocks: metro-testing, metrov1backlog
No longer blocks: metrov1planning
Summary: Hooking up devtools, profiler to metro → Story - Hooking up devtools, profiler to metro
Whiteboard: feature=story c=testing u=developer p=0
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.
Depends on: 870081, 859372
Whiteboard: feature=story c=testing u=developer p=0 → feature=story c=testing u=developer p=0 [waiting on devtools]
Attached patch patch courtesy of harthur (obsolete) — Splinter Review
Blocks: 872780
Blocks: metrov1it9
No longer blocks: metrov1backlog
Hi Ally, can you provide a point estimate for this feature story.
Flags: needinfo?(ally)
QA Contact: jbecerra
Flags: needinfo?(ally)
Whiteboard: feature=story c=testing u=developer p=0 [waiting on devtools] → feature=story c=testing u=developer p=0
p=13. It's uncharted territory with a brand new api
Whiteboard: feature=story c=testing u=developer p=0 → feature=story c=testing u=developer p=13
Status: NEW → ASSIGNED
Priority: -- → P2
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.
(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
- 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
Attachment #752858 - Attachment is obsolete: true
Attachment #762438 - Attachment is obsolete: true
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 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.
Depends on: 833507
Component: General → Metro Operations
Product: Firefox for Metro → Tracking
Version: unspecified → ---
Depends on: 886546
Depends on: 886555
Blocks: metrov1it10
No longer blocks: metrov1it9
Blocks: metrov1it9
No longer blocks: metrov1it10
Blocks: metrov1it10
No longer blocks: metrov1it9
Depends on: 888079
Depends on: 888111
The metro-side work has been finished off. Unassigning myself.
Assignee: ally → nobody
Blocks: metrov1backlog
No longer blocks: metrov1it10
Status: ASSIGNED → NEW
QA Contact: jbecerra
Whiteboard: feature=story c=testing u=developer p=13 → [waiting on devtools] feature=story c=testing u=developer p=13
No longer blocks: 872780
Blocks: metrobacklog
No longer blocks: metrov1backlog
No longer blocks: metro-testing
Summary: Story - Hooking up devtools, profiler to metro → Hooking up devtools, profiler to metro
Whiteboard: [waiting on devtools] feature=story c=testing u=developer p=13 → [waiting on devtools] [story]
Priority: P2 → --
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
No longer depends on: 963629
Product: Tracking → Tracking Graveyard
You need to log in before you can comment on or make changes to this bug.