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.
Related
Is there a way to open devtools on production builds of Electron that were packaged and distributed to you?
For instance, I'd like to poke around Slack's app. I know that it's built in Electron, and I'd like to open devtools to see how some parts of it are built.
On macOS I've tried:
ELECTRON_ENV=development /Applications/Slack.app/Contents/MacOS/Slack --debug --auto-open-devtools-for-tabs
as well as the usual key combination of Cmd+Option+I and checking for debug menus/views.
None of these seem to make a difference.
Note that there are already a few solutions that recommend you do it programmatically by injecting:
remote.BrowserWindow.getFocusedWindow().webContents.openDevTools()
However I can't do that because I don't have access to the source code or the original build process. Is there a way to trigger devtools externally?
The most promising way I've seen so far is remote-debugging-port but I'm not sure it works with production builds.
The way to do this without third-party code is indeed using the --remote-debugging-port flag.
Using Signal as an example, take the following steps:
start the application from the CLI
signal-desktop --remote-debugging-port
Open the debugging URL in a Google Chrome browser (in this case http://localhost:39733/), this will open a page with the app name on it .
Click the to open a screen were you can click around to use the app and see output in the devtools
Alternatively, you can open chrome://inspect/#devices in the Google Chrome browser and click "inspect" (underneath the app name) to open the same window
If I start a Node.js process with the --inspect flag then I get a URL in the console for me to debug the application using Chrome dev tools.
eg
Debugger listening on
ws://127.0.0.1:9229/fa66d6b2-2011-4e4f-bafc-fc9a300a36d5
If I make a change to my application, I need to restart the application process, and this results in a completely new debug URL.
This is inconvenient because I already have Chrome dev tools pointing at the old URL.
How can I have the process automatically restart on application source code changes and maintain the same dev tools debugging session to avoid the need to manually reconfigure dev tools for every change?
You can use the Node Inspector Manager plugin. It has the ability to listen to the inspector and automatically open in a new tab. This is a big part of my development workflow.
I'm creating an Firefox extension which is required to load a list of regular expression from a certain URL. But, if this called every time user load a page, it will be too painful for the server. So, I want the program to run once every time a user is starting Firefox.
I've found this solution:
How to detect first loading of NPAPI plugin/Extension in firefox and chrome
But it has a downside. If the Firefox starts with multiple tabs, it will not work (gBrowser.browsers.length don't have "1" as value).
So, what should I do?
Where did you read that extension code is executed every time a user loads a page? By default, extension code on Firefox only runs on
install
enable
startup
upgrade
downgrade
So, just make the request in main.js and you should be fine.
If you really want the list to only load on startup (which doesn't sound like what you would actually want), then add the line
if (require("sdk/self").loadReason==='startup') loadRegexs()
I'm experiencing a strange intermittent issue with Chrome Developer tools hanging on to old versions of JavaScript files. I'll be developing some JS app, things humming along just find, and then all the sudden my JavaScript files will disappear from the list of JavaScript files on the "sources" tab. This is my first clue that something is wrong.
What I eventually discovered is that Chrome Developer Tools is, apparently hanging on to an old version of the JavaScript file. Chrome itself is requesting and executing the latest version from the server, but you can't debug the JavaScript file.
I "proved" to myself that this was what's happening by taking a particular JavaScript file that had disappeared from my sources list, and replacing it with a one line console.log statement.
I then reloaded the page, and noted that the console.log statement appeared in the JavaScript console. I also noted in the Network tab that the JavaScript file was successfully retrieved, and that what came down over the wire contained just the one line console.log statement.
However, the JavaScript file still didn't appear in the sources list, and if I clicked on the filename in the console (where it appears on the righthand side of the console, next to the logged statement), then I jump to the sources tab, and an old version of the JavaScript file is opened.
This JavaScript file is loaded onto the page via a regular <script> tag. It is not loaded dynamically, via another script, or via eval. Just a plain, vanilla <script> tag that points to the .js file on the webserver.
I've tried:
Ensuring that "Disable cache (while DevTools is open)" is checked in the DevTools settings.
Manually clearing out my cache and cookies in Chrome.
Restarting Chrome
Manually loading the JavaScript file in a separate Chrome tab
Disabling every Chrome extension/app that I have installed
Running the page in incognito mode
Uncheck both "Enable JavaScript source maps" and "Enable CSS source maps"
None of these changed the behavior. You can watch a video demonstrating this here, if you don't believe me!
I do think it's a Chrome issue, as I can use Firefox without this issue... but I really like Chrome and Chrome's developer tools :-) So I'd like to get this working in Chrome...
Update I reported this as a Chrome bug here. If this bug is affecting you, or important to you, please vote it up and/or add comments with additional information.
Chrome DevTools works fine for me. When I load it for a page it remembers beyond the lifespan of the chrome process what sources I have open; although it gets the order wrong. I see two differences in our devtools prefs: disable cache and enable maps. So I would advise:
1) uncheck disable cache (while DevTools is open),
2) (if 1 didn't work) press the "Restore defaults and reload" button.
The issue persists in 78.0.3904.97. To fix it run settings > advanced > reset.
Some code editors such as rubymine cache js files.
To solve for rubymine: File > Invalidate Cache/Restart
As suggested here https://groups.google.com/d/msg/google-chrome-developer-tools/2rolf--fJ3M/UTJQaZN3K28J, for development environment I added these headers when serving a sourcemap:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
and it seems to do the job (at least for now).
I am working on a small web api project in Visual Studio 2013 Ultimate. Windows 2013. Internet Explorer 9. When I run (debug) from VS using the internal web server (I guess that is IIS Express, now), I am finding that the changes I am making (and saving) to a javascript page are being ignored. Placing a breakpoint in the javascript shows the older code without my changes.
CTRL+F5 does not force the application to use the currently updated page. Checking the page in, then checking it back out often works. Is there some setting or trick that will help me out here?
Clearing the cache history seemed a bit excessive and I don't want to do that all the time.
The following solution worked me in Internet Explorer:
First enable script debugging:
Tools menu -> select Internet Options
On advance tab uncheck "Disable script debugging (Internet Explorer)"
Then make sure you get the newest page:
From the Tools menu choose Internet Options.
On the General tab, under Browsing history, click Settings.
Under "Check for newer versions of stored pages" make sure "Every time I visit the webpage" is selected.
Click the OK button.
If somebody has this problem and ctrl+F5, clearing browser's cache, restarting debugging, changing browser, changing web.config and rebuilding project don't help, then there is one last thing that works (at least for me): restart Visual Studio.
Also changing debugging port on local IIS Express helps but this is far more painful if working in a team or using Azure Active Directory etc.
Only solution that worked for me was changing the javascript file name and updating the bundle configuration to point at the new file. I tried everything else from restarting my pc, deleting bin/obj/cache/etc, CTRL F5, restart IIS, and so on.
If I'm correct you should build (ctrl+shift+b) your project before debugging. This web server runs in the background on a port of choosing whenever you start in debug mode. You can close the task(s) (process bar next to your clock) if you need a new session or press F5 in VS.
You can avoid using the built in web server if you have IIS (Express) or something similar.
Go to RUN and type iis depending on your OS it's already installed. Otherwise try to install it in Control Panel > Programs or Features > Turn windows features on or off
add a website (site name, path, hostname)
add to your host file 127.0.0.1 hostname (c:\windows\system32\drivers\etc\hosts)
To debug your project in Visual Studio:
open your website on your hostname in your favourite browser
click on DEBUG
click on ATTACH TO PROCESS
find w3wp.exe
hit ctrl+f5 in your browser to start debugging server code
Depending on how your solution/project is setup, you can publish your project files directly to IIS if you choose to publish to File System. Right mouse click on your project and choose publish. Set it up from there.
If your Visual Studio is up-to-date you can publish single files with alt+$+p.
Hope it helps.
Locate the code section where the JavaScript file is loaded to the page and add a parameter string to the end for testing. For example:
Change src="../Resources/js/MyScriptFile.js"
To src="../Resources/js/MyScriptFile.js?v=23"
Every time you update your JavaScript file, you change the version number. This will force the browser to load your new version of JavaScript file. After you finished testing, You can remove the string "?v=23". The bonus, if you leave it there, the end user will not be required to refresh his/her browser cache after you deployed your code to production.
I keep getting this problem very often. Normally what I do is first get into the drive where the OS is installed (In my case C:), and delete all the application.dll and application.pdb (it is stored in Windows\Microsoft.net\Framework\vx.x.xxxxx\Temporary ASP.NET Files). Delete application.dll and application.pdb in the users\xxx. Get into the application directory and again delete application.dll and application.pdb. Clear the browser cache. Restart the system (cold restart). Build the application. Most of time found to be working.
Note: I use DOS prompt for deleting since I'm quite used to it. But the user should have admin privileges. It's not a perfect solution but it works.
What worked for me was
Shutdown Visual Studio 2013 update 2 (I have win 8.1 all 64 bit)
Delete clear out "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
Cleaned and Rebuilt solution
Restart IIS Express. If using IIS just re start app and pool.
Run in VS 2013 Debug (F5) it still loads the old file under Script Documents > Windows Internet Explorer > Page_Name.aspx
Then F12 Developer tools clear Browser Cache (IE), I have the same issue in Chrome
F5 in browser reload the page finally loads the changed JS script file with my debugger; entry and breakpoints set
So i had the same problem and i could avoid this by canceling the .ASP.NET-Server
.ASP.NET-Server from Visual Studio for debugging
from Visual Studio and restarting the debugging. Hope this helps someone.
I restarted Visual Studio and rebuilt the project, but the problem persisted for me -- the debugger continued to run an old copy of the .js file. The solution for me was to simply reboot the machine. (When all else fails...)
For reference, I'm currently using Visual Studio 2015.