STR: 1. Open the Web Console. 2. Open the Browser Debugger. 3. Select webconsole.js from the scripts drop-down. 4. Search for JSTF_keyPress(). 5. Set a breakpoint inside the function you found. 6. Start typing the Web Console input. Expected result: execution pauses in JSTF_keyPress at the breakpoint you add. Actual result: nothing happens. Execution is not paused.

I'm morphing this bug a little as we've found some more information. It looks like we're also unable to debug scripts loaded in XUL files in general. I tested both the webconsole.js case and the debugger-controller.js case. I can set a breakpoint in those files but am unable to trigger the breakpoint even though I am exercising that line of code.

For what it's worth: Our sole onNewScript handler is ThreadActor.prototype.onNewScript, which calls ThreadActor.prototype._addScript, which calls ThreadActor.prototype._allowScript to decide whether to add the script to our tables. _allowScript ignores scripts that have no url, or whose urls begin with "chrome://" or "about:". Would any of that be a problem here?

(In reply to Jim Blandy :jimb from comment #2) > _allowScript ignores scripts that have no url, or whose urls begin with > "chrome://" or "about:". Would any of that be a problem here? The Browser Debugger attaches to the ChromeDebuggerActor, which overrides _allowScript ignoring only scripts without a URL.

Any update on this?

Mihai's testcase in Comment #0 is still valid, despite the scripts in question showing up in the debugger. See attached debug log from my session.

walking through the testcase in comment #0. note the inner connection when I open the webconsole. See the breakpoint get set at line 52. DBG-SERVER: Got: { "to": "conn2.chromeDebugger2", "type": "setBreakpoint", "location": { "url": "chrome://browser/content/devtools/webconsole.js", "line": 3112 } }

Why does that log contain only the packets sent from client to server, and not the server's responses?

(In reply to Jim Blandy :jimb from comment #7) > Why does that log contain only the packets sent from client to server, and > not the server's responses? To get logs from both sides in chrome debugging, one needs to additionally set devtools.debugger.log in the automatically-created profile for the browser debugger. That is called something like blahblah_chrome-debugger-profile. Adding it to prefs.js (or user.js) before starting the debugger will work.

I should add that my hope is that the fix for bug 820012 will take care of this one, too.

(In reply to Panos Astithas [:past] from comment #9) > I should add that my hope is that the fix for bug 820012 will take care of > this one, too. It actually does!

Fixed by bug 820012.