AFAIK, there is no more Javascript tracer available in tree.

This is unfortunate as it would greatly help debugging our JS codebase.
This is especially useful when it comes to understand why something goes wrong after a given action/test code and you have no clue what code is being trigger.
Setting a breakpoint doesn't help as the bug may happen in another event loop.
You might use the "pause on next interupt" feature of the debugger, but it may require stepping through way too many frames.

This is where a Javascript tracer would significantly help debugging.
The tracer would simply print all the javascript frames being executed, then you may easily discover what is the unexpected code that runs and crash your test or feature.

case study

I was investigating an unexpected race condition in the following test
https://searchfox.org/mozilla-central/rev/e94c6cb9649bfe4e6a3888460f41bcd4fe30a6ca/devtools/client/styleeditor/test/browser_styleeditor_syncAddProperty.js#25-51

  for (const URI of URIs) {
    await addTab(URI);
    const { inspector, view } = await openRuleView();
    [...]
    const { ui } = await openStyleEditor();
    [... doing many things in the inspector and style editor ...]
  }

I immediately saw that there was an issue with this for loop.
When we were processing the second URI, and so in the second for loop, the first URI's tab was actually focused, causing many failures.
So I had to figure out what code was late-focusing the tab from the first loop execution.
But I had absolutely no clue what that code was.

Using the old prototype I had from bug 1721427, I figured it out immediatly.
I simply added this in the test:

  for (const URI of URIs) {
    await addTab(URI);
    const { inspector, view } = await openRuleView();
    [...]
+  const { traceAllJSCalls } = ChromeUtils.import(
+     "resource://devtools/shared/thread-helpers.jsm"
+  );
+  traceAllJSCalls();
+  await new Promise(()=>{});
  }

And got the following logs in stdout:

 0:06.11 GECKO(119874) --[interpreter]--> resource://devtools/client/framework/toolbox-host-manager.js @ 166:20 - _onMessage
 0:06.11 GECKO(119874) --[interpreter]--> resource://devtools/client/framework/toolbox-hosts.js @ 92:4 - raise
 0:06.11 GECKO(119874)  --[interpreter]--> resource://devtools/client/framework/toolbox-hosts.js @ 427:23 - focusTab
 0:06.11 GECKO(119874)   --[interpreter]--> chrome://browser/content/tabbrowser.js @ 302:8 - set selectedTab
 0:06.11 GECKO(119874)    --[interpreter]--> chrome://browser/content/browser-webrtc.js @ 22:32 - willShowSharedTabWarning
 0:06.11 GECKO(119874)    --[interpreter]--> chrome://global/content/elements/tabbox.js @ 77:10 - set selectedTab
 0:06.11 GECKO(119874)     --[interpreter]--> chrome://global/content/elements/tabbox.js @ 47:10 - get tabs
 0:06.11 GECKO(119874)     --[interpreter]--> chrome://global/content/elements/tabbox.js @ 614:10 - set selectedItem
 0:06.11 GECKO(119874)      --[baseline]--> chrome://global/content/elements/tabbox.js @ 471:6 - get selected

which was exactly what I was looking for. This code late-focus the previous tab.

How to bring this feature to developers

1. Simpliest option for us would be to suggest manually importing this JSM and do what I did
2. Slightly easier option would be to provide a test helper in devtools shared-head.js to simplify this
3. if we want to reachout to all mozilla-central contributors, we may expose such test helper in xpcshell and mochitest test helpers
4. or, we may expose that to web developers by bringing a JS tracer back in the debugger (we used to have a preffed off one for a little while)

Such feature would actually be beneficial to Web compat team who is often trying to understand what code runs and break the website on firefox.

For now, I will try to move forward with option 2.

Before introducing to a broader audience, we can start using that within the devtools team.

Denis, I saw that you were working on tracers. You might have valuable feedback about my work here.

There was a tracer already in SpiderMonkey, but it was difficult to maintain and enabled only under certain build flags and not by default due to it's overhead. However, it was only ever really used for performance investigations and it was actually recently removed entirely in favor of jitdump sampling with perf.

Oh I thought it was removed a long while ago!

Any opinon on a tracer implemented in JS?
Here we don't have performance in sight, this is rather for debugging and discover undercover code.
The main benefit is that it reuses the spidermonkey API used to implement breakpoints, so it is low-cost maintenance!

I unfortunately don't have any opinion on this matter as I haven't needed to use one for debugging. However, I'll delegate this to Ted if he has any thoughts about re-implementing the tracer for debugging purposes.

https://hg.mozilla.org/mozilla-central/rev/e50716441d84