Inspecting elements and runtime log statements always returns undefined

I just switched from Nightly to Developer Edition because I figured this was an issue with some configuration or setting I had for Nightly but it seems like it’s still happening. It was happening on Nightly for many months, maybe a year or so (not sure when I first noticed it).

When I step through JavaScript in the debugger, hovering over any variable shows that it has an undefined value. This is the same thing for when I add in log statements via the devtools. When I explicitly add a console.log statement in my code then it logs properly, but I’d prefer to be able to inspect elements in realtime as I’m debugging.

Is there some setting I might have ticked or an extension I have installed (uBlock origin, Vue devtools, React devtools, Redux devtools, or LastPass) that could be causing this issue to happen?

Hello @bradydowling, would you have a small test app we could check to reproduce this issue?
If not, could you give us more information of the type of the value you’re expecting (object, arrays, …) ? Thanks!

Good point. I tried it on a vanilla hello world script and it was working fine. It looks like it’s probably something with the React .js file I’m running.

Our project is using Gradle to run some web server but I don’t understand it too well yet. I’m going to dig into that more and then I’ll post back here once I find out the cause.

Update: After further digging, it’s worth noting that Firefox is able to show values for a standard React app created with create-react-app so it’s not directly cause by React itself, likely some special build step as I mentioned above.

Also worth noting that I’m able to inspect variables real-time in Chrome so this is indeed limited to Firefox, not just a general issue with my build process.

I don’t think I’ll be able to dig into this as I’d like to right now. That said, for future reference, our build process is setup following this guide and we’re using react-scripts 3.0.1.

@bradydowling in Debugger, do you have the Map option in the Scopes panel enabled? It would be good to check if inline tooltip/preview are broken; if you can verify that the variables are shown correctly in the Scopes panel.


Interesting, I never noticed that. It seems like it’s the same with and without it enabled. As you can see in the screenshot, the date variable is undefined but once I check in the Scopes panel, there’s a variable there (e) that contains the value for date. The same is the case for other variables as I step through.

I hadn’t noticed this before so this is a helpful workaround at least. I tried closing the debugger and opening it again, refreshing the page, etc. but those didn’t help.

Might be something where Firefox is more strict in parsing source maps. Do your source maps validate in ?

Honestly, we just created our app using create-react-app so I haven’t ever touched our sourcemaps. I kind of just figured this was something Firefox picked up for me so I don’t even know where they’d be in a standard CRA app.

Fortunately, this issue seems to be fixed now. Unfortunately, I don’t know what I changed that made this happen. I’d guess it was related to checking/unchecking the Map box that was mentioned above but I can’t be sure. Sorry I can be more certain on this but thank you for the help!

I had the same problem with Firefox v110.0 (64-bit). The value of class variables would always be undefined when I hovered over them. I tried debugging the same code in Chrome and it worked perfectly fine there.

The solution that worked for me was to check the ‘Map’ checkbox.

1 Like

Wow that was not obvious to me as the scopes tend to be below the fold for me on my tiny laptop screen. Thanks!

It’s curious to me why this isn’t enabled by default, I feel like most devs would be they want it on and then sometimes the rare occasion you don’t want the sourcemap abstracting it. One of the more frustrating aspects of Chrome DevTools was that there was no easy way to disable source mapped variables on the fly, and Firefox it’s easy but not so obvious.

This isn’t enabled by default because this is quite a slow operation.
We’re currently working on making it faster so we can enable it by default, and we’ll also modify the UI to make things more obvious