When I run node --inspect app.js it says "Debugger attached". Then I open up chrome://inspect and I see my app running there so I click either Open dedicated DevTools or Inspect (next to the app's name). No matter how I open Node DevTools though, it just doesn't seem to be connected to anything (I can't see the source code there, the debugger statements are ignored, nothing logs to the console etc). I also tried opening it by opening regular DevTools and clicking the green Node icon.
It's weird because Chrome clearly sees the server running and something is clearly connecting to Node (and I don't think there's anything else on my network that could do that) but I still can't get DevTools to even acknowledge the server's existence.
I also distinctly remember debugging something the same exact way a few weeks ago and back then everything worked fine (although I remember I also struggled with this a bit but I somehow got it to work at the end, I think attaching the name of the file at the end of the command instead of in putting it in the middle did the trick at the end). The only thing that's happened since then is that I updated from v8 to v10 (LTS)
I've obviously tried rebooting and also reading every manual and article about node --inspect out there, nothing helped.
Chrome version: 92
For me, the problem was The Chrome DevTools was not looking for the connection port my Node.js process was using.
I did the following:
Start the node process with --inspect flag. It started the process on port 9239.
Type chrome://inspect/#devices in Chrome address bar.
Click "Open dedicated DevTools for Node" in the devices page.
It opens the "DevTools-Node.js" window.
Click the "Connection" tab.
Click "Add connection" button.
Type localhost:9239 in the text box and click "Add".
After adding the correct port, the DevTools connected to the Node.js process and I was able to debug it.
I was facing same problem, I have solved it by
1) Updated chrome to latest version and relaunched it
2) Restarted node --inspect server.js
3) Noted port number as shown here
port number
4) Opened chrome://inspect and added localhost: port number noted in step 3
update connection in chrome
use command instead of node --inspect:-
node --inspect-brk
Seems to be a new chrome issue: https://github.com/nodejs/node/issues/26887
Related
The command:
node-debug sls offline
opens a new browser window every time it is run.
How do we stop it from opening a new window every time? I want to reuse the existing window!
This is a known issue with node inspector. Take a look here.
Since 0.9.0 we use https://github.com/benderjs/browser-launcher2 to
start the browser, and make sure it's Chrome/Chromium/Opera (i.e. the
browsers that can properly render node inspector; we detect installed
browsers in the system and choose the most appropriate one; earlier we
used opener module which just delegated opening the browser to the OS,
which would open the defaul browser, which could have been e.g.
Firefox) and this could be the reason why the behavior has changed.
browser-launcher2 actually does a bit more than just launching a
browser, for instance it creates a new profile for Chrome in a
subfolder of ~/ - this is probably the issue that #CalvinScott
reported (i.e. Chrome that was opened was the new profile created by
browser-launcher, not your original profile; you should be able to
open your original profile of Chrome normally)
Also, you may consider this:
Since version 6.3, Node.js provides a buit-in DevTools-based debugger
which mostly deprecates Node Inspector, see e.g. this blog post to get
started. The built-in debugger is developed directly by the
V8/Chromium team and provides certain advanced features (e.g.
long/async stack traces) that are too difficult to implement in Node
Inspector.
Once a node.js program has run to completion in the context of an --inspect session (i.e. via the Chrome dev tools debugger) is it possible to re-start it without having to re-issue the --inspect command from the command-line?
The issue with re-issuing an --inspect command is that it generates a different chrome url every time and one has to then copy-paste this into Chrome each time. Ideally I want to be able to push F5 to re-start the chrome debug session.
So two issues:
I cannot restart the debug session without killing the current (i.e. no way to just refresh).
I have to copy paste the url into chrome each time I start a new session. (not as bad as issue 1.)
Here's a couple of options for you, though neither will provide you with a simple F5 refresh, both are significantly better than copy/pasting the new URL generated by the --inspect flag.
The most optimal solution is installing this extension for Chrome or Opera: https://chrome.google.com/webstore/detail/nim-node-inspector-manage/gnhhdgbaldcilmgcpfddgdbkhjohddkj
This will manage the node inspector for you. Just click the resulting toolbar icon and select "Auto" from the toggle switch. Your browser will then open the Chrome DevTools in inspection mode whenever your node server generates an inspection URL.
If you want to go the low-tech (and more manual) route, or don't want to install a Chrome extension, just open your Chrome to "chrome://inspect", wait a moment, and you'll get a list under Remote Target that will include your Node server. Just click the "inspect" link there, and the DevTools will open with the current URL. The downside of this method is you'll need to reclick that "inspect" link every time your server restarts. It avoids copy/pasting URLs, but still involves manual labor.
It's also significant to note that if you simply update the url of your inspector with the new ID, it will also work.
When you restart node, you'll get something like this:
Debugger listening on ws://127.0.0.1:9222/72c791b7-178f-47e8-93b1-d1be4d5ffe1e
The bit after the port/ is what you want. Replace that code in your inspector's url and it will connect to the latest session.
I created a VS Cordova project, and need to download some data from a web service, but Ripple runs inside Chrome, and Chrome considers that request "cross-domain" and blocks it. Setting ripple proxy option to disabled/local/remote has no effect. I can start another instance of Chrome with --web-security-disabled command line option, point it to the same URL http://localhost:4409/... and application works fine in that second Chrome. Now all I need is to find a way to pass --web-security-disabled to Chrome when I start it by pressing F5 in Visual Studio. It's probably somewhere in some config file, just need to find it ...
It is difficult to know without looking at the exact code, but it is likely that one of a few of things is happening:
Your code is bypassing the CORS proxy in Ripple
Proxying through Ripple is resulting in the web server denying the request.
You have the Ripple extension installed in Chrome. In effect you can end up with two Ripples running which can cause a number of unexpected behaviors.
To know which is happening, be sure the CORS proxy is set to "local" and check the network tab. An XHR call to www.bing.com would look something like this:
http://localhost:4400/ripple/xhr_proxy?tinyhippos_apikey=ABC&tinyhippos_rurl=http%3A//www.bing.com
Try just doing this from your index.html page and see if it succesfully goes through the proxy.
var xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET", "http://www.bing.com", true);
xmlhttp.send();
If you need to further debug or you want to use Ripple outside of Visual Studio, you can actually install the Ripple npm package and use it outside of Visual Studio. Build for Android in the debug config, then go to the bld/Debug folder and execute the following from the command prompt:
npm install -g ripple-emulator
ripple emulate android --port 12345
A browser Window will appear. Paste that into Chrome if its not your default and retry. You can then see what is going through the proxy in the command prompt.
You can also use this same method to debug your app using the Chrome Dev Tools with --web-security-disabled.
Before the recent firmware update, web-based debugging (at port 9222) would persist between activities. Now any transition, say from the home screen to my app, stops the debugger with a message at the top saying...
Detached from the target
Remote debugging has been terminated with reason: target_closed.
Please re-attach to the new target.
It's not a huge problem to start a new debug window, but I'm worried that if the debugger isn't running when my app is loaded I won't get the benefit of the "Disable cache (while DevTools is open)" option.
Any details or workarounds would be appreciated.
UPDATE
Confirmed! In my case at least, the debugger stops with the above error and the latest version of my html, javascript, etc. does not get loaded
Try this as a work around and see if it works: when your page is loaded, run window.location.reload() in the debug console to reload the page (so you get a full debugging info from the beginning without missing anything) or window.location.reload(true) to do the same and clear cache as well.
I have installed the tor browser bundle on a linux system. I start it from the command line by
:~$ ./.tor/tor-browser_en-US/start-tor-browser
This will first launch vidalia and then open a preconfigured tor browser. If I close the browser, then vidalia is still running, but I don't know how to 'get back' the tor configured browser. Is there a hidden button on the vidalia panel or something that will get a browser running? I cannot find any.
What I do now, is to exit vidalia, and run the script again, thus reconnecting to the tor network and all. This is time consuming and seems unnecessary. What am I doing wrong?
I found this Link: https://askubuntu.com/questions/217092/restart-tor-browser-after-closing
Maybe there is no solution at the moment.