We Keep Coding

How can I resolve the Chrome warning: The deferred DOM Node could not be resolved to a valid node

I'm running a node.js project on a localhost server, and I've been doing this for months without seeing this, but recently, I've been getting this warning when I open the inspector:
The deferred DOM Node could not be resolved to a valid node.
I usually go into the inspector on an element to check out some attribute, eventListener, or other info, but this warning is popping up and it doesn't take me to the element. It's been pretty annoying, and I don't really know why it started showing up or how to get rid of it. My only clue is that I was changing some initialization settings for my express sessions around the same time this appeared, but I'm not sure that this is related.
Has anyone else run into this before? How do you get rid of the warning?
Thanks!

In my case, closing and reopening the browser window fixed it

That might be due to a chrome extension interfering. Make sure you test in an environment with no extensions like incognito mode.

This can occur when debugging in Visual Studio. Usually, restarting the debugger solves the problem

Open it in a incognito mode in chrome works!

I'm seeing this in Microsoft Edge right now (chromium version).
Never been aware of seeing it before and I don't have any extensions installed in Edge.
It currently works in Chrome! It also works in Edge in the live website but not my local machine.
In other words 🤷.

How can I hit breakpoints (and see error line numbers) when debugging javascript on Android?

I'm trying to follow these instructions for debugging android javascript.
I am aware of How can I debug javascript on Android?, but it's not clear to me how (or if) I can hit breakpoints - either using Chrome on the Android device, or the Android browser.
I can see and 'inspect' the device OK:
But breakpoints don't get hit, nor can I see line numbers on the errors in the console:
Between these two problems, I'm not getting much useful information from the debugging experience! I have tried going to 'about:debug' in the android browser, and do see the debug options appear.
I will add that the js I am debugging works fine in the latest Chrome on the same Android device.

First off, it seems like there are a bunch of syntax errors that may be preventing mustache.js from executing at all - see if you can take care of those first.
I'd try setting a breakpoint on the next line down - line #9 - to see if anything in that IIFE is running at all.

Assuming you are using a module bundler (such as Webpack) in development (based on port 8080 in your screenshot), most likely the code you're trying to debug is executed via eval. In which case by the time you can see it in the devtools, it has already run.
You can either use the debugger statement in your code, or running in production mode - where there's a real script file being executed. In both cases, you should attach the remote debugger first, and only then navigate to your page (or refresh it).

I have now tried the same thing again, and this time didn't experience the problem. Unfortunately I can't put my finger on what the problem was exactly, as due to my dev machine dying I am running a new windows 10 installation, and potentially a different version of the Android SDK and ADB. The phone and android browser haven't changed.
Anyway, I can now set and hit breakpoints as I'd expect:
I also get better error descriptions and line numbers:
FWIW, the only problem that needed fixing was changing some 'let' declarations to 'var'.

Why would my app crash in Chrome if I refresh a few times?

I'm building a web app that does a lot of DOM manipulation and uses CSS3 effects.
I'm repeatedly refreshing the page, and on every 4th or 5th reload, Chrome displays the Aw, snap page indicating a tab crash. I think the page is consistently crashing around that many refreshes, so I don't think it's a probabilistic thing, but rather stems from something building up.
How can I examine Chrome crashes to find out some potential culprit causes? I've tried taking CPU profiles and heap snapshots, and it doesn't look like I'm accumulating much memory.

We to are experiencing the same thing in latest chrome version 40.0.2214.111 on multiple computers.
We logged a bug with Chromium here: https://code.google.com/p/chromium/issues/detail?id=456365
Feel free to add comments / star to help get on their radar.
It seems tough to debug as there is no crash data and running debug tools themselves will cause crashes.
We have not been able to re-produce in Chrome Canary.

We were having the same issue using last version of chrome (40.0.2214.111).
In our case the app is using SoundJS and if we disable webaudio api for this library, the app is working ok.
if (navigator && navigator.userAgent && navigator.userAgent.match("40.0.2214.111")) {
createjs.Sound.registerPlugins([createjs.HTMLAudioPlugin]);
} else {
createjs.Sound.registerPlugins([createjs.WebAudioPlugin, createjs.HTMLAudioPlugin, createjs.FlashPlugin]);
}
don't know if your are using SoundJS but just in case I wanted to add this comment.

Android Chrome constantly crashing with my HTML5 website -- How to debug it?

i have built a HTML5 web site (or rather webapp as you wish) and it works fine in Chrome and firefox. I would say the only thing out of the ordinary is, that it uses
Google Closure in some parts (the issue persists in the simplest, non-optimized mode)
HTML5 canvas for 2D drawing
Now I was curious whether it would run on my Galaxy Tab Tablett and indeed it does. I was able to set up the remote debugging facility https://developers.google.com/chrome-developer-tools/docs/remote-debugging?hl=de and debug my code to get rid of a few things that were not working properly. However I notice that android-chrome regulary crashes while I use my app. The console in my desktop browser then complains about websocket being closed (thats why I suspect it really is a problem of the tablet side).
I would like to know what makes my website crash and am a bit flubbergusted that my HTML/js site can crash a browser like chrome so easily. I would have thought that it should be more stable than that.
Now as I would like to have an "entry" point into debugging the issue:
is there a crash log of chrome for android that I can inspect somehow?
can I somehow make it (chrome or android in general) more verbose on error messages?

There are a couple of things that you can do:
chrome://crashes will list the crashes that it has caught when a tab crashes - you might need to turn on crash reporting in the settings. You won't be able to fix it but you will be able to report it us so we can see if it is an issue.
Use logcat and see if there are any specific issues in the tracing output, such as an out of error message.

How can I test potentially "browser-crashing" JavaScript?

I've been having a crack at some of the problems over at http://projecteuler.net/ with JavaScript. I've been using a simple html page and running my code in script tags so I can log my results in the browsers' console. When experimenting with loops I sometimes cause the browser to crash.
Is there a better environment for me to do this kind of development?

a browser that has separate processes for each tab
debugger breakpoints
an if that breaks the loop if some threshold for time is hit

If you're running computationally expensive programs in your browser, you may want to look at using web workers. In short, they allow you to run code in a different thread which won't lock up the browser.

If you are just interested in running javascript programs as such, why don't you use something like node.js or even Rhino? That way you can easily log output without loosing it if it get into 'trouble'.

I can think of two ready possibilities:
1) Use a debugger that has breakpoints. Firebug is rather nice. Safari and Chrome also have some built-in debugging tools.
2) You could move your testing out of the browser using Mozilla Rhino and Env-js (see http://groups.google.com/group/envjs and http://github.com/thatcher/env-js )

All modern browsers (except Opera) should interrupt your script if it runs for more than 5-10 seconds (Source).
In Firefox you can even lower this threshold, if 10 seconds mean a too big punishment. Also note that this mechanism kicks in even when you run code from the Firebug console:
Stop Script on Firefox http://img819.imageshack.us/img819/9655/infloopsp.jpg
I think this feature alone should provide a pretty safe environment for these loopy experiments :)

There's nothing you can do to keep the browser from crashing other than fix bugs that cause the browser to crash.
You can at least mitigate the impact of the crash by using a browser like Chrome that generally segregates crashes in one tab from the others (so you lose only your own page), or just installing a separate browser specifically for testing.
In terms of keeping track of data that might have gone to the log, you might use a plugin like Firebug that has a built-in debugger so you can pause the script execution partway through and examine your variables, presumably before any crash occurs.