--jsdebugger does not halt on "debugger;" statements in content frame scripts
Categories
(DevTools :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: ato, Unassigned)
Details
Comment 2•7 years ago
|
||
(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #0)
The Browser Toolbox Debugger for chrome is opened and halts on "debugger;"
statements when Firefox is launched with the --jsdebugger flag. Having the
ability to set breakpoints like this in your file is an immensely powerful
debugging technique, as it is not always possible to coordinate adding
breakpoints by hand when starting Firefox or when Firefox is under
automation.
Correct, this works well.
It is however not possible to make the debugger halt when setting
breakpoints in content frame scripts. Whilst it is my understanding that it
is possible to debug frame scripts by changing the debugger context by
selecting the targetted document in the right-hand corner of the UI, the
debugger does not automatically open and break on "debugger;" statements
in frame scripts.
I am not sure if I understand this part.
Is the following STR describing what you have in mind?
STR:
- Open http://janodvarko.cz/tests/bugzilla/1468603/ (it should break in an content iframe when you reload the page with content debugger opened)
- Close Firefox and change the settings so the page is opened on startup
- Append
--jsdebuggerto your command line - Run Firefox again
- The debugger doesn't break in the iframe
So, it only breaks with the content Toolbox.
Honza
| Reporter | ||
Comment 3•7 years ago
|
||
I think I may not have explained myself well enough in comment #0.
The concrete problem I have is that using a debugger; statement
in a frame script loaded by a system XPCOM component, does not
automatically break when you run it with the --jsdebugger flag.
An example:
-
Add
debugger;somewhere in testing/marionette/listener.js,
for example inregisterSelf. -
Run any Marionette test:
% ./mach marionette-test --jsdebugger
-
Click the button in the dialogue that appears to have the tests
run.
Perhaps there is something we’re not doing to instrument the
browser the right way for the content debugger to open?
Andreas, I can remember we discussed that with Mike Conley a long time ago during an all hands meeting. By that time he mentioned how to do that. But actually I cannot remember the/a bug where we documented that. :/
Maybe he can help again, and we finally document it.
Comment 5•7 years ago
|
||
The Browser Toolbox connects to and only notices scripts running in the parent process. Frame scripts running in the content process will not be noticed by it.
There's a secondary toolbox - the Browser Content Toolbox - which attaches to the currently selected tab's content process. This is what you want to open to see your breakpoint. You can find the Browser Content Toolbox menu item inside the Web Developer menu.
Unfortunately, I don't believe there's a command-line argument that allows you to open the Browser Content Toolbox - although that might be good to have (presumably connecting to the initial tab's content process).
| Reporter | ||
Comment 6•7 years ago
|
||
Right, I filed this bug after our conversation at an All Hands, and
I think it would be a powerful debugging technique to have
--jsdebugger also halt and open the correct debugger on debugger;
in content frame scripts. Do you agree that’s reasonable?
As I understand it, --jsdebugger sets these prefs:
devtools.browsertoolbox.panel→jsdebuggerdevtools.debugger.remote-enabled→ truedevtools.chrome.enabled→ truedevtools.debugger.prompt-connection→ false
So if I interpret your reply correctly, we’d need additional pref(s)
in DevTools to open the Browser Content Toolbox?
Comment 7•7 years ago
|
||
(In reply to Andreas Tolfsen ⦗:ato⦘ from comment #6)
So if I interpret your reply correctly, we’d need additional pref(s)
in DevTools to open the Browser Content Toolbox?
Yes, I think that's probably what you want here.
Updated•7 years ago
|
Comment 8•7 years ago
|
||
Moving to devtools > general so that we can open the discussion to the larger devtools team.
Comment 9•7 years ago
|
||
The priority flag is not set for this bug.
:pbro, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•7 years ago
|
Updated•3 years ago
|
Description
•