Open Bug 1283363 Opened 8 years ago Updated 2 years ago

Hitting a breakpoint in a content script renders the console unusable

Categories

(DevTools :: Console, defect, P2)

47 Branch
defect

Tracking

(Not tracked)

People

(Reporter: robwu, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

When I use the devtools console to create an object (e.g. [] or {}), and then switch to a different JS environment, then the console does not accept any new JS commands. It fails with the error "Debugger.Object belongs to a different Debugger".

To reproduce, first create a directory with the following files:
manifest.json
  {
    "name": "Some WE addon",
    "version": "1",
    "manifest_version": 2,
    "content_scripts":[{"js":["contentscript.js"],"matches":["*://*/*"]}],
    "applications": {"gecko": {"id":"devtoolsbug@id"}}
  }

contentscript.js
  console.log('Hello');
  onhashchange = function(e){
    debugger;
  };

STR (steps-to-reproduce) for Firefox 47.0.1:
1. Start Firefox, visit about:debugging.
2. Click on the "Load Temporary Add-on" button and select manifest.json from above.
3. Open the devtools and Enable browser debugging if needed.
4. Visit example.com
5. Open the browser's toolbox (Cmd-Opt-Shift-I or Ctrl-Alt-Shift-I).
6. Select the example.com "frame" as target.
7. Go back to the tab from step 4, edit the URL and append #foo (to trigger the hashchange event).
8. The devtools will now trigger a breakpoint and be switched to the content script JS environment.
9. Type [] and press Enter.
10. You will see "Array [ ]". Continue the execution.
11. Type [] and press Enter.
12. I expect to see "Array [ ]", but get the following stack trace instead:

error occurred while processing 'evaluateJSAsync: TypeError: Debugger.Object belongs to a different Debugger
Stack: WCA_evalWithDebugger@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:1282:16
WCA_onEvaluateJS@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:872:20
WCA_onEvaluateJSAsync@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:842:20
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
DebuggerTransport.prototype._onJSONObjectReady/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:479:9
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
Line: 1282, column: 16

Note that the bug still occurs if I execute step 7 and 8 after step 10.


STR for Firefox Nightly 50.0a1 (2016-08-29):
1. Start Firefox, visit about:debugging
2. Click on the "Load Temporary Add-on" button and select manifest.json from above.
3. Visit example.com
4. Open the devtools for the tab (Cmd-Opt-K or Ctrl-Shift-K)
5. Continue from step 6 in the above STR (for Firefox 47)



ADDITIONAL INFO

If you switch back to the original JS environment, and execute a snippet that generates a primitive value (string, number, boolean, ...), then the devtools will start to behave normally again. Until you execute the above STR, then it breaks again...

1. (follow the previous STR to get the devtools in a broken state).
2. Trigger a breakpoint using step 7 (or exit the breakpoint if you followed the Nightly STR).
3. Type "9" (any primitive value will do) and press Enter.
4. Continue the breakpoint (or activate the breakpoint if you followed the Nightly STR).
5. Type [] and press Enter.
6. Note that the devtools prints "Array [ ]" as expected.
So, I'm not sure if this is the only problem - but I see the same problem I saw in Bug 1283641, which is the error trying to get a localized string to print that the frame has switched followed by the 'too much recursion' error.
Depends on: 1283641
Priority: -- → P2
OK, I've confirmed the problem using STR.  Unfortunately the issue sticks around even if you switch frames back to browser.xul
Attached file sample-web-extension.zip (deleted) —
Zipped up test case for the extension
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: