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

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.

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.

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.

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.

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

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.

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?

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