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.