953414 - Can't debug content scripts

Status: RESOLVED INVALID

(DevTools :: Debugger, defect, P3)

Description

[David Bruant]

Steps (Aurora 28 and Nightly 29 with fresh session using cfx run):
1) create an addon with content scripts [1]
2) open the browser toolbox debugger (the script are present in the script list)
3) set a breakpoint somewhere in the content script (I didn't experience problems with addon code)
4) hit that code (the debugger does stop at the breakpoint)
5) Try to step in

Expected:
step into the code

Actual:
The debugger doesn't step, it's impossible to play the script, the browser is entirely blocked.

I'm starting the bug as is in case the problem is obvious to someone or if it's a duplicate. If it's not, needinfo me for a reduced test case (I noticed that on a big addon so it takes some time to reduce the test case)

[1] https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Content_Scripts

Comment 1

[David Bruant]

Needinfo'ing Panos for the Debugger side and Irakli for the Jetpack part. Feel free to pass along if you're not the right person.

Comment 2

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

I am not sure exactly how an addon's content scripts are loaded, but this feels similar to the work I'm doing in bug 946813 to allow the debugger to be loaded via the addon SDK without breaking stepping in the browser toolbox.  In that case, there is a desire to mark the in-process debugger as "invisible" so the browser toolbox's debugger instance does not get confused.  Perhaps a similar technique is needed here.

Comment 3

[David Bruant]

Looks related indeed. I'm pre-emptively setting a dependency and wait for bug 946813 to be fixed. I'll retest what I feel is broken in this bug and report if my problem is fixed.

Comment 4

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

Well, I may have misrepresented the current state of bug 946813...  A patch has already landed to revert the regressing behavior, so it should currently be possible to step through most code via the browser toolbox.  The rest of that bug will involve making use of this "invisible" to debugger setting, so that the bad change can be relanded without causing trouble.

This issue seems independent (since it's currently broken, when general stepping works at the moment), so I don't expect this problem to be resolved automatically by bug 946813.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

I can't think of anything that would explain this off the top of my head. A test case would be most welcome.

Comment 6

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Looking at the comments in bug 946813 I'm tempted to assume this is related but Ryan seems to suggest
it won't automatically get fixed.

Only special thing about content scripts is that they are loaded in their own sandbox that has same
principals as a content document they're attached to. They also have direct access to the content
document they're attached to, other than that they are no different from the sandboxes we create for
regular add-on modules.

Comment 7

[Eddy Bruel [:ejpbruel]]

Irakli, I'm considering whether we need to bump the priority on this. How common would you say the need to debug content scripts is for add-on developers?

Comment 8

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Eddy Bruel [:ejpbruel] from comment #7)
> Irakli, I'm considering whether we need to bump the priority on this. How
> common would you say the need to debug content scripts is for add-on
> developers?

I agree! Most commonly used SDK APIs is page mod that is built around content scripts, there for I would expect majority of add-on's authors trying to use debugger will run into this bug.

Comment 9

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

Debugging add-on content scripts works for me just fine. Note that I am using the standard (web) Toobox not the Browser toolbox.

Honza