Now that the remote browser debugger can attach to add-on scripts, it is possible to debug add-ons with it. Doing so is still cumbersome, however, since the browser debugger attaches to all globals regardless of whether they are part of a specific add-on or not. What we want is for the browser debugger to attach to a specific add-on, rather than the entire browser.
In terms of implementation, our proposal is to create a specialization of the chrome thread actor used by the debugger, which we will call an add-on thread actor (bug 898559). In contrast to the chrome thread actor, which adds *all* globals as debuggees, an add-on thread actor only adds globals that are part of a given add-on.
In addition, the root actor should be extended to respond to a request for a list of add-ons by sending a reply containing a list of add-on thread actors, one for each (active) add-on. Clients can then attach to/detach from these add-on thread actors on an individual basis.
The add-on thread actor must be able to tell which globals are part of a given add-on and which are not. To facilitate this, we propose implementing a metadata API (bug 898559) which allows globals to be tagged as such.
Once we've implemented add-on thread actors, we propose to extend the add-on manager UI with an option 'debug this add-on' for each active add-on. Clicking this option will cause the browser debugger to be started for a specific add-on (by passing it the add-on ID as a parameter).
(In reply to Eddy Bruel [:ejpbruel] from comment #1)
> In terms of implementation, our proposal is to create a specialization of
> the chrome thread actor used by the debugger, which we will call an add-on
> thread actor (bug 898559). In contrast to the chrome thread actor, which
> adds *all* globals as debuggees, an add-on thread actor only adds globals
> that are part of a given add-on.
For anyone else reading and being confused like me: I think the bug number was meant to be bug 899052.