1661178 - Debugger will not show call stack when debugging content scripts

Status: NEW

(DevTools :: Debugger, defect, P3)

Description

[John Nagle]

Attachment: Screenshot of debugger not showing call stack

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Started Firefox, dev version 81.0b1, 64-bit, Linux, with a near-new profile.
Enabled Browser Content Toolbox
Loaded temporary add-on (my "Ad Limiter", which is on AMO). No compressed or obfuscated files.
Loaded page with a Bing search result for "Hacker News".
Set breakpoint.
Reloaded page to begin debugging.

Actual results:

Content script stops at breakpoint and debugger shows "stopped". Sometimes the Call Stack appears. Sometimes it doesn't. When it shows, variables can be examined. Single stepping (F10) makes the call stack go away. Reloading Firefox brings it back. Sometimes.

The shading which shows the line at which control stopped works, and moves with single stepping even after the content script disappears. But if control leaves the area visible in the window, there's no indication of where control went.

Debugging of content scripts just does not work.

Firefox page process crashed once. Bug report automatically submitted. No ref number available since the crash reporter did not give me one.

Expected results:

Call stack should always appear when the debugger is stopped at a breakpoint or single stepping.

When stopped, the current line of code should always show.

Comment 1

[John Nagle]

Attachment: Debugger crashing.

Page under debugging crashed.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report!

We can't reproduce the problem on Win10 and Mac, perhaps it's Linux specific?

Nicolas, you have Linux (VM) correct? Could you please test it?
Note that the STRs are using the Content Toolbox.

Honza

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

I was able to reproduce the issue, not sure what's happening though.
John, as a workaround, you might try to use the Browser Toolbox to debug your addon

Comment 5

[John Nagle]

Re workaround: The Browser Toolbox can't debug a content script, I think. That's the whole point of having the Browser Content Toolbox.

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks Nicolas for testing!

(In reply to John Nagle from comment #5)

Re workaround: The Browser Toolbox can't debug a content script, I think. That's the whole point of having the Browser Content Toolbox.

Nicolas is talking about Multiprocess Browser Toolbox (Browser Toolbox with support for all processes). It's enabled in Firefox Nightly by default, and opened the same way as Browser Toolbox (the difference you can see is the browser window title saying: "Multiprocess Browser Toolbox")

This Multiprocess Browser Toolbox will replace the Browser Content Toolbox eventually (i.e. Browser Content Toolbox will be removed).

Honza

Comment 7

[John Nagle]

Wasn't the browser toolbox for all processes, the “Omniscient Browser Toolbox", enabled back in 2019?

Ref: https://blog.nightly.mozilla.org/2019/11/13/these-weeks-in-firefox-issue-68/

I thought that's what I was using with the Browser Content Toolbox. Or is that being replaced by something else this year?

Incidentally, the add-on I'm testing, the identical files in WebExtension format, seems to be working fine under Chromium. Someone else suggested I try Chromium's debug tools, but there's no problem to debug over there.

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to John Nagle from comment #7)

Wasn't the browser toolbox for all processes, the “Omniscient Browser Toolbox", enabled back in 2019?
Ref: https://blog.nightly.mozilla.org/2019/11/13/these-weeks-in-firefox-issue-68/

That's correct. That blog post points to bug 1588050 where we enabled the “Omniscient Browser Toolbox" (later renamed to Multiprocess Browser Toolbox) in Nightly by default.

I thought that's what I was using with the Browser Content Toolbox. Or is that being replaced by something else this year?

The "Multiprocess Browser Toolbox" is Tools -> WebDeveloper -> Browser Toolbox
The "Browser Content Toolbox" is Tools -> WebDeveloper -> Browser Content Toolbox

As soon as the "Multiprocess Browser Toolbox" is stable and enabled on all channels (Release, Beta, DevEdition, Nightly) we'll remove the "Browser Content Toolbox" since even content processes can be debugged by "Multiprocess Browser Toolbox" at such point.

Honza

Comment 9

[Lyubomir [:mystiquewolf]]

I'm opening the popup of an extension in a tab (easier that way) and the Call Stack doesn't appear. Also, there are calls to async functions with .then() and i have breakpoints inside .then()'s callbacks and the line that surrounds the current stopped line doesn't show up of the .then()'s callbacks. It shows in the (global) and it shows in the functions that call browser APIs, but not in the .then() calbacks for them. While this happens Firefox still shows "Paused while stepping".

The above happened in the about:devtools-toolbox page before i opened the Multiprocess Browser Toolbox mentioned above. After i opened it i reloaded the extension via about:debugging and then about:devtools-toolbox showed the call stack. This time it didn't stop inside the callbacks of the Browser async APIs, although there are breakpoints there. For example this code below:

function getSkip(){
	browser.runtime.sendMessage({
		want: "skip"
	}).then((oSkip) => {
		console.trace("getSkip > browser.runtime.sendMessage want skip.then > .then");
		arrSkip = oSkip.list;
	}).catch((err) => {console.log('Problem getting skip list: '+err.message);});
}

I am stepping through code with "Step Into" and i am at line browser.runtime.sendMessage..., i execute it with F11 and debugger stops at the last closing } bracket. Please note that i have breakpoint at the line console.trace, but debugger doesn't stop there. And although debugger doesn't stop, the console.trace() is logged in the Console the moment i press F11 while i'm on the line browser.runtime.sendMessage().

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Lyubomir, thank you for the comment!
Could you share your extension so, we can try your case and reproduce the issue on our machines?

Comment 11

[Lyubomir [:mystiquewolf]]

Attachment: Troubleshooting info

Well, it's not my extension but i just debug it to see its workings. It is this one: https://addons.mozilla.org/bg/firefox/addon/switch-to-previous-active-tab/

Comment 12

[Lyubomir [:mystiquewolf]]

Attachment: Troubleshooting info

Well, it's not my extension but i just debug it to see how it works. It is this one: https://addons.mozilla.org/bg/firefox/addon/switch-to-previous-active-tab/

Comment 13

[Lyubomir [:mystiquewolf]]

So i run the following to open the popup in a tab. I run it by typing in the Console of about:devtools-toolbox?id=%7Bf01b6ea5-5910-4359-afee-9f0de052c7a1%7D&type=extension

browser.tabs.create({
		active: true,
		url: "popup.html"
	})

Comment 14

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Screenshot from 2021-09-01 12-36-27.png

I tried to reproduce the issue with the following STR (based on comment 12 and comment 13):

• installed addons linked in comment 11 as temporarily installed from about:debugging
• opened the addon debugging window by clicking inspect on the extension just installed
• typed the API method call from comment 13 to open the extension popup
• switched the addon debugging window to the extension popup using the frame selector from the developer toolbox toolbar
• set a breakpoint on the first line of the getSettings function part of popup.js
• reloaded the extension page previsoult opened in a new tab by the snipper from comment 13

The breakpoint was hit and the call stack seems to be the expected one (see attached screenshot).

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Screenshot from 2021-09-01 12-41-45.png

As an alternative STR:

• open the extension popup into a tab using the snippet from comment 13 (typed in the background page of the same extension using the console panel from the addon debugging window)
• open the developer toolbox associated to the tab where the extension page has been loaded
• set a breakpoint on the first statement inside the getSettings function defined in popup.js
• reload the tab

Also in this case the breakpoint was hit and the call stack seems to be the expected one (see screenshot attached).

Comment 16

[Luca Greco [:rpl] [:luca] [:lgreco]]

As a side note, in the following doc page there are some more detailed info about how to debug an extension popup without having to force opening it in a browser tab (along with how to reach with the developer tools other parts of the extension):

• https://extensionworkshop.com/documentation/develop/debugging/#debugging-popups

Comment 17

[Lyubomir [:mystiquewolf]]

Attachment: List of breakpoints.png

Yes, getSettings() gets hit. What doesn't get hit/stopped at are the callbacks for the async functions once the getSettings() breakpoint gets hit. I'm not sure if i should open a new separate bug about it.

Call stack now appears, but yesterday it did not appear until i opened the multiprocess browser toolbox and reloaded the extension.

Comment 18

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Lyubomir from comment #17)

Yes, getSettings() gets hit. What doesn't get hit/stopped at are the callbacks for the async functions once the getSettings() breakpoint gets hit. I'm not sure if i should open a new separate bug about it.

This bug was originally about missing call stack related to extension content scripts, but I'm not yet 100% sure if the underlying issue is likely the same or two different ones. From my perspective it can be fine to still investigate it as part of this bug (at least until we are sure if there are two separate underlying issues or not).

Call stack now appears, but yesterday it did not appear until i opened the multiprocess browser toolbox and reloaded the extension.

and in the meantime I've been able to reproduce the missing call stack, it seems to be happening in the addon debugging developer toolbox after it got into some inconsistent state (but I haven't been able yet to spot any error or other logged message that may be related to entering that inconsistent state), closing and reopening the addon debugging developer toolbox makes the call stack to be visible again once the same breakpoint is hit (which is likely why you were not able to reproduce it again when you retried it).

Comment 19

[ger]

This issue is happening for me. No call stack and no scope. The code window also removes every line before the last dozen sometimes.
I'm just an old learner using Javascript and Firefox so I'm slow, but those bugs really kill the process.