899054 - (dbg-addon) [meta] Add-on debugging

Status: NEW

(DevTools :: Debugger, task, P5)

Description

[Eddy Bruel [:ejpbruel]]

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).

Comment 1

[:Gijs (he/him)]

(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.

Comment 2

[Jason Laster [:jlast]]

Honza, Harald, could you triage this meta?

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Done
Honza

Comment 4

[dnsproxyserver]

Attachment: root

Approval Request Comment
[Feature/Bug causing the regression]:
[User impact if declined]:
[Is this code covered by automated tests?]:
[Has the fix been verified in Nightly?]:
[Needs manual test from QE? If yes, steps to reproduce]:
[List of other uplifts needed for the feature/fix]:
[Is the change risky?]:
[Why is the change risky/not risky?]:
[String changes made/needed]:

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

Which older supported branches are affected by this flaw?

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

How likely is this patch to cause regressions; how much testing does it need?

Comment 5

[dnsproxyserver]

Description:
Please provide an explanation of the feature or change. Include a description of the user scenario in which it would be used and how the user would complete the task(s).
Screenshots and visual UI specs are welcome, but please include sufficient accompanying explanation so that blind members of the accessibility team are able to understand the feature/change.

How do we test this?
If there is an implementation to test, please provide instructions for testing it; e.g. setting preferences, other preparation, how to trigger the UI, etc.

When will this ship?
Tracking bug/issue:
Design documents (e.g. Product Requirements Document, UI spec):
Engineering lead:
Product manager:

The accessibility team has developed the Mozilla Accessibility Release Guidelines which outline what is needed to make user interfaces accessible:
https://wiki.mozilla.org/Accessibility/Guidelines
Please describe the accessibility guidelines you considered and what steps you've taken to address them:

Describe any areas of concern to which you want the accessibility team to give special attention: