1495673 - xpcshell debugging is broken on a debugger actor's exception - source property is not undefined nor a Debugger.Source object

Status: NEW

(DevTools :: Debugger, task, P3)

Description

[Alexandre Poirot [:ochameau]]

When debugging an xpcshell test, I get the following exception:
  query object's 'source' property is not undefined nor a Debugger.Source object
And the toolbox immediately closes.

STR:
* run an xpcshell in debug mode:
  ./mach xpcshell-test devtools/shared/security/tests/unit/test_encryption.js --jsdebugger

* Open another firefox
* Open the connect page via system menu: Tools > Web developer > Connect...
* Click on "Connect" button

See the toolbox that closes and observe the exception from ./mach xpcshell-test.

Comment 1

[Mark Banner (:standard8)]

This works for me if I do:

./mach xpcshell-test --jsdebugger browser/components/urlbar/tests/unit/test_UrlbarController_integration.js

However, if I use the test_encryption that you are, then I get the same result as you do.

Comment 2

[Alexandre Poirot [:ochameau]]

oh I didn't thought about that. May be this test messes with the DebuggerServer.

Comment 3

[Alexandre Poirot [:ochameau]]

The issue comes from this code:
https://searchfox.org/mozilla-central/rev/819cd31a93fd50b7167979607371878c4d6f18e8/testing/xpcshell/head.js#411-417
          // Add a breakpoint for the first line in our test files.
          let threadActor = subject.wrappedJSObject;
          for (let file of breakpointFiles) {
            // Pass an empty `source` object to workaround `source` function assertion
            let sourceActor = threadActor.sources.source({originalUrl: file, source: {}});
            sourceActor._getOrCreateBreakpointActor(new OriginalLocation(sourceActor, 1));
          }
It is not clear how and if we can still set a breakpoint for files that aren't evaluated yet.
Here for xpcshell, we are trying to set a breakpoint for `file` (i.e. the absolute path to the xpcshell file we would like to break on) on its first line.
We worked around a previous exception by passing an empty object as source object as we can't have a valid DebuggerSource object.

Comment 4

[Jason Laster [:jlast]]

What is the status of this bug?

Comment 5

[Jason Laster [:jlast]]

I think this should be fixed.

Comment 6

[Logan Smyth [:loganfsmyth]]

The

query object's 'source' property is not undefined nor a Debugger.Source object

exception is indeed fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1514248

The test does however still fail at https://searchfox.org/mozilla-central/source/devtools/shared/security/tests/unit/test_encryption.js#25

equal(DebuggerServer.listeningSockets, 0, "0 listening sockets");

though. I assume because it is detecting the test debugger connection itself as a listener. We could potentially adjust the test to try to handle this, but I'm not sure it would be worth it? IDK. Alex, do you care about that, or are we good to close this?

Comment 7

[Alexandre Poirot [:ochameau]]

(In reply to Logan Smyth [:loganfsmyth] from comment #6)

The test does however still fail at https://searchfox.org/mozilla-central/source/devtools/shared/security/tests/unit/test_encryption.js#25

equal(DebuggerServer.listeningSockets, 0, "0 listening sockets");

though. I assume because it is detecting the test debugger connection itself as a listener. We could potentially adjust the test to try to handle this, but I'm not sure it would be worth it? IDK. Alex, do you care about that, or are we good to close this?

We may want to load xpcshell's DebuggerServer in a dedicated loader in order to avoid such issue.
https://searchfox.org/mozilla-central/source/testing/xpcshell/head.js#387
({ require } = ChromeUtils.import("resource://devtools/shared/Loader.jsm", {}));

And flag the dedicated loader via invisibleToDebugger=true in order to be able to debug correctly any devtools module, including the thread ctor.
We do this for the browser toolbox here:
https://searchfox.org/mozilla-central/source/devtools/client/framework/ToolboxProcess.jsm#129-131