Error thrown after adding a breakpoint

I’m not sure what has happened, but all of a sudden, the WebExtension I am working on started to throw an error when debugging. So far as I’m aware, there was no change to the code to cause the error. I even rolled back to an earlier version of the extension in order to see if I had inadvertently caused a problem by adding something to the scripts I couldn’t remember adding, but that didn’t help the situation.

Everything seems to be find until I add a breakpoint. After adding a breakpoint to the debugger in the FireFox Developer browser, an error is thrown, and I am unable to step through the code. Previously, I was able to set breakpoints and step through code normally, but it will not work any longer. I’ve searched for answers online, but I’m not able to understand the error enough to gain any traction. Here is the error the console is writing:

error occurred while processing 'frames: TypeError: window is null Stack: webExtensionChildPrototype.isExtensionWindow@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/webextension.js:284:3 webExtensionChildPrototype._allowSource@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/webextension.js:304:13 TabSources/this.allowSource@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:30:39 source@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:118:12 createNonSourceMappedActor@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:357:12 getFrameLocation@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:587:7 form@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/frame.js:93:31 onFrames@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/thread.js:949:18 onPacket@resource://devtools/shared/base-loader.js -> resource://devtools/server/main.js:1761:15 receiveMessage@resource://devtools/shared/base-loader.js -> resource://devtools/shared/transport/transport.js:735:7 enter@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/event-loop.js:118:5 _pushThreadPause@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/thread.js:178:5 _pauseAndRespond@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/thread.js:390:7 hit@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/breakpoint.js:188:12 appAPI.CallCrossDomain@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/appapiclass.js:92:8 CheckLoginProcess@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:1434:4 FireLogin@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:1632:5 DrawLoginUI/<@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:181:6 dispatch@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/jquery.js:5182:16 add/elemData.handle@moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/jquery.js:4991:6 Line: 284, column: 3 main.js:1616

_unknownError resource://devtools/server/main.js:1616:5 onPacket resource://devtools/server/main.js:1764:29 receiveMessage resource://devtools/shared/transport/transport.js:735:7 enter resource://devtools/server/actors/utils/event-loop.js:118:5 enter self-hosted:981:17 _pushThreadPause resource://devtools/server/actors/thread.js:178:5 _pauseAndRespond resource://devtools/server/actors/thread.js:390:7 next self-hosted:1219:9 hit resource://devtools/server/actors/breakpoint.js:188:12 appAPI.CallCrossDomain moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/appapiclass.js:92:8 CheckLoginProcess moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:1434:4 FireLogin moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:1632:5 DrawLoginUI/< moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/popup.js:181:6 dispatch moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/jquery.js:5182:16 add/elemData.handle moz-extension://d059ac7f-1fe3-7649-b7ca-e14cb93b87b0/popup/scripts/jquery.js:4991:6

I can provide code snippets if needed, but since the error is only thrown after I add the breakpoint, I don’t know what code would be helpful for leading to a solution. Also, I’m using the latest FireFox Developer Edition browser for debugging.

I’m hoping I have not missed something silly here, but I have searched for “window is null”, “TypeError: window is null”, “'frames: TypeError: windows is null” as well as other debugging searches in relation to jQuery and WebExtensions in general, but I can’t find any information leading to a solution. Any help would be much appreciated.

Setting breakpoints in Firefox is can be weird. Sometimes they only capture the first asynchronous line of execution passing them and let later ones pass. That can create race conditions which would be impossible otherwise.

Just try not setting the breakpoint and either do console.log debugging (might want to JSON.parse(JSON.stringify()) clone the values if they are modified after logging them) or debug with Chrome.

Thank you for your response @NilkasG. I am hoping that I’ll be able to step through our code for debugging. Are you saying that when you debug WebExtension code you are working on, you simply place console statements throughout the code? I used to do that with general web design, but I was really hoping to get away from that for our browser extension.

And when you say, “or debug with Chrome”, are you saying that Chrome’s debugging tools work better for stepping through code?

I don’t generally do that, but some things in WebExtensions are highly asynchronous and sometimes racy by design. Putting breakpoints in there will necessarily influence the timing (what you see shouldn’t happen, though).
In those cases I go with console statements.

are you saying that Chrome’s debugging tools work better for stepping through code?

Definitely. Firefox has made some improvements, especially when it comes to debugging multiple execution contexts, but the Chomium developers havn’t been sleeping either.
There are a number of things I dislike about Chrome, but it’s DevTools are better than those of Firefox, especially if you look at the little things, like stepping over await, the ability to set breakpoints at every statement (not just the line) and that you can explicitly target content scripts.

So if you can load your extension in Chrome as well (with polyfills and maybe some missing features) and are stuck debugging, give Chrome a shot.
Even though you won’t be able to debug behavior specific to the other browser.