1096759 - With e10s, addon cannot access DebuggerServer instance

Status: RESOLVED INVALID

(DevTools :: General, defect)

Description

[James Long (:jlongster)]

Apparently the debugger server runs within the content process (not exactly sure how that works). I'm trying to get access to the debugger server within an addon to register a new actor type. The normal way to do this is like this:

const { DebuggerServer } = Cu.import("resource://gre/modules/devtools/dbg-server.jsm");
DebuggerServer.registerModule('file:///Users/james/projects/mozilla/channel-debugger/actors/channels.js', {
  prefix: 'channels',
  constructor: 'ChannelActor',
  type: { global: true, tab: true }
});


However, it appears that this creates a new DebuggerServer instance, even though `dbg-server.jsm` internally uses `require` which before e10s would make it always return the same one. Now I'm guessing that my addon is running in a different process, so I can't access the debugger server to extend it.

I verified this with some debug output; the most convincing was I assigned a random ID to the server and there are 2 separate ones in the log.

I need to learn more about e10s and how this is all hooked up, but is this possible at all?

Comment 1

[James Long (:jlongster)]

Seems like Alexandre has worked with this code a bit (I was looking at content-server.jsm). Do you mind explaining how all this works? The debugger server runs in the content process to access all the local JS objects, right? Is there any way to access that from an addon?

Comment 2

[James Long (:jlongster)]

I may need to just RTFM. This page is very helpful: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox. Looks like I finally need to learn everything about frame scripts.

Comment 3

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Where is your add-on code?  It should be possible to access the "main" / chrome / parent process debugger server from your add-on, instead of whatever you seem to be getting now, but I think looking at your code may be the simplest path.

Comment 4

[James Long (:jlongster)]

(In reply to J. Ryan Stinnett [:jryans] from comment #3)
> Where is your add-on code?  It should be possible to access the "main" /
> chrome / parent process debugger server from your add-on, instead of
> whatever you seem to be getting now, but I think looking at your code may be
> the simplest path. 

It's a bit of a mess right now, but: https://github.com/jlongster/channel-debugger. This is where the main init happens (and is problematic in e10s): https://github.com/jlongster/channel-debugger/blob/master/content/main.js#L170.

I'm not touching the DebuggerServer right now. I just hook a Debugger straight into the window object and do my own stuff, and register a devtool panel to display results. I need to use the DebuggerServer, register and actor, and use the protocol to talk to it instead, which where I'm trying to go. Right now I'm just trying to get a basic actor installed and able to talk to it over the e10s architecture.

You can see some commented out code at the top of bootstrap.js where I'm playing around with the message manager, which loads in this frame script to see if this works: https://github.com/jlongster/channel-debugger/blob/master/content/frame.js

Comment 5

[James Long (:jlongster)]

I got it to work! I load a frame script here: https://github.com/jlongster/channel-debugger/blob/master/bootstrap.js#L7. The frame script registers the module: https://github.com/jlongster/channel-debugger/blob/master/content/frame.js. Now you can see that the response to `listTabs` includes the channelActor:

PM info DBG-SERVER: Received packet 2: {
  "from": "root",
  "selected": 0,
  "tabs": [
    {
      "actor": "conn0.child1/tab1",
      "title": "",
      "url": "about:blank",
      "channelsActor": "conn0.child1/channelsActor2",
      "consoleActor": "conn0.child1/consoleActor3",
      "inspectorActor": "conn0.child1/inspectorActor4",
      "callWatcherActor": "conn0.child1/callWatcherActor5",
      "canvasActor": "conn0.child1/canvasActor6",
      "webglActor": "conn0.child1/webglActor7",
      "webaudioActor": "conn0.child1/webaudioActor8",
      "styleSheetsActor": "conn0.child1/styleSheetsActor9",
      "styleEditorActor": "conn0.child1/styleEditorActor10",
      "storageActor": "conn0.child1/storageActor11",
      "gcliActor": "conn0.child1/gcliActor12",
      "traceActor": "conn0.child1/traceActor13",
      "memoryActor": "conn0.child1/memoryActor14",
      "framerateActor": "conn0.child1/framerateActor15",
      "eventLoopLagActor": "conn0.child1/eventLoopLagActor16",
      "reflowActor": "conn0.child1/reflowActor17",
      "cssUsageActor": "conn0.child1/cssUsageActor18",
      "monitorActor": "conn0.child1/monitorActor19",
      "timelineActor": "conn0.child1/timelineActor20",
      "profilerActor": "conn0.child1/profilerActor21"
    }
  ],
  "url": "chrome://browser/content/browser.xul",
  "channelsActor": "conn0.channelsActor3",
  "consoleActor": "conn0.consoleActor4",
  "inspectorActor": "conn0.inspectorActor5",
  "canvasActor": "conn0.canvasActor6",
  "webglActor": "conn0.webglActor7",
  "webaudioActor": "conn0.webaudioActor8",
  "styleSheetsActor": "conn0.styleSheetsActor9",
  "styleEditorActor": "conn0.styleEditorActor10",
  "memoryActor": "conn0.memoryActor11",
  "framerateActor": "conn0.framerateActor12",
  "eventLoopLagActor": "conn0.eventLoopLagActor13",
  "cssUsageActor": "conn0.cssUsageActor14",
  "monitorActor": "conn0.monitorActor15",
  "timelineActor": "conn0.timelineActor16",
  "profilerActor": "conn0.profilerActor17",
  "chromeDebugger": "conn0.chromeDebugger18",
  "preferenceActor": "conn0.preferenceActor19",
  "webappsActor": "conn0.webappsActor20",
  "deviceActor": "conn0.deviceActor21"
}

Now I just need to figure out how to get to that, as none of the clients seem to keep those extra actor ids around... I think this can be closed though.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I think https://bugzilla.mozilla.org/show_bug.cgi?id=977443 is what you really want?

Comment 7

[James Long (:jlongster)]

(In reply to Nick Fitzgerald [:fitzgen] from comment #6)
> I think https://bugzilla.mozilla.org/show_bug.cgi?id=977443 is what you
> really want?

Having not looked at that patch, why is `registerModule` insufficient? I have a working addon that adds an actor to the server (even over e10s) and can talk to it over the protocol. I'm sure that bug has advantages, but I'm just curious what the 30 second summary of them are.

When that lands it won't be too hard to just use that instead of the frame script.

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Unless you also install the addon on Firefox for Android / Firefox OS, it won't work with remote debugging.

Comment 9

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Nick Fitzgerald [:fitzgen] from comment #8)
> Unless you also install the addon on Firefox for Android / Firefox OS, it
> won't work with remote debugging.

And Firefox OS does not have addons at all today, so you would really need bug 977443 in that case.

Comment 10

[James Long (:jlongster)]

Good point. Although I don't really understand how you will load code remotely onto the device. But that will be a nice benefit when that lands, and should be easy to switch to that.