1185464 - The new extension API should come with debuggability

Status: RESOLVED WORKSFORME

(WebExtensions :: Untriaged, defect, P1)

Description

[Gabor Krizsanits (INACTIVE)]

This might just work out of the box, it's unclear at this point. But it would be great if add-ons based on the new extension API were debuggable.

Comment 1

[Michael Henretty [:mikehenrty][:mhenretty]]

Gabor, does this bug report cover seeing injected content_scripts in the debugging panel of devtools/webIDE, as well as setting breakpoints therein?

Comment 2

[Gabor Krizsanits (INACTIVE)]

(In reply to Michael Henretty [:mhenretty] from comment #1)
> Gabor, does this bug report cover seeing injected content_scripts in the
> debugging panel of devtools/webIDE, as well as setting breakpoints therein?

Yes this it should cover that.

Comment 3

[Mindaugas <LA-MJ>]

It seems FF46 has a regression.

Using the 'Debug' button in about:addons leads to a debugger session with no sources.
FF45 on the other hand displays a background script and a generated bootstrap

Comment 4

[Andy McKay]

I'm not sure what this means and its not really actionable. I do not that in about:debugging you can hit the debug button in Firefox 48 and debug background scripts, content scripts and a whole pile of stuff. Luca has been taking this to the next level and we are working on this in Q3.

I'm closing this as works for me because what we have works pretty well right now.

Comment 5

[Nancy Grossman]

(In reply to Andy McKay [:andym] from comment #4)
> I'm not sure what this means and its not really actionable.

If you don't know what it means, how do you know that it's not actionable? And if it's not actionable, how can you be "working on this in Q3"?

If you're not sure what it means, you should ask for clarification. The OP has been here almost daily.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Does it work to debug content scripts with e10s enabled? I wouldn't expect the "Debug" button to be able to do that unless there have been some major devtools changes. That code runs in a different process.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Nancy Grossman from comment #5)
> (In reply to Andy McKay [:andym] from comment #4)
> > I'm not sure what this means and its not really actionable.
> 
> If you don't know what it means, how do you know that it's not actionable?
> And if it's not actionable, how can you be "working on this in Q3"?

I've started to work on this after an analysis of the major pain points, discussed and validated my plan with a DevTools team member during MozLondon and finally the split of the strategy into actionable steps.

Follows a link to the google doc which summarizes the plan:

- https://docs.google.com/document/d/1-irEoJ5Ri6MKG708Q_WvyaOaDfyYoHjg4cR6-Fvj0wk

The issues that I'm currently working on are:

- Bug 1281451 - Provide a link to a MDN Add-on Debugging doc page in the about:debugging page
- Bug 1268773 - After reloading an addon with the add-on debugger opened, the debugging global should be updated
- Bug 1285556 - Add an isWebExtension getter to the AddonWrapper
- Bug 1285557: Create a WebExtensionAddonActor based on the ChromeActor and TabActor

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Bill McCloskey (:billm) from comment #6)
> Does it work to debug content scripts with e10s enabled? I wouldn't expect
> the "Debug" button to be able to do that unless there have been some major
> devtools changes. That code runs in a different process.

As commented on Bug 1189556, the content scripts are currently visible and debuggable from the tab developer tools of their related web page.

I would really like to unify them with the other webextensions contexts that are running in the main process, but it is not currently possible, and the current strategy described above is the same used in Chrome and the Addon SDK for making the content scripts debuggable, and so it should not be surprising for the addon developers. 

The toolbox that is currently opened by pressing the "Debug" button in the "about:debugging" page is pretty limited (mostly because it has been designed based on how the legacy addons technologies do work), but it already able to provide (with some known issues, unfortunately):

- a webconsole panel, which points to the background page (if any) 

- a debugger panel, which gives access to any of the addon sources that are running in the main process (which are the sources of all the webextensions contexts, besides the content scripts which are running in the content process, as Bill pointed out)

The changes that I'm planning and working on (as described in the google document linked in Comment 7) will provide a more complete (and hopefully less buggy) Addon Developer Toolbox when the addon is a WebExtension, which has all the feature that are available in the tab or the Browser toolbox (in the above google docs there are links to a screencast of the prototype and to Nightly prebuilt binaries for Windows/OSX/Linux with the proposed patches applied).

Comment 9

[theodorebethune1207]

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Affects Firefox for Android]:
[Suggested wording]:
[Links (documentation, blog post, etc)]: