I just created a new project and have run it for the first time using F5 or Ctrl + F5. The result in Chrome is:
The site can't be reached
err_connection_refused
I checked the option at the breakpoints for "Exceptions caught" and the following error is displayed.
Without "Exceptions caught" checked, the next error raised:
I tried to run "ng s -o" from the terminal and all work fine. The site is working well on port 4200, but I like to debug.
Here is my launch.json file, all by default:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:4200",
"webRoot": "${workspaceFolder}"
}
]
}
Why is this happening?
I also had this issue and none of the solutions listed were helpful.
However, the problem was rather easy to solve.
Just go into the Network tab of the Chrome Developer Console. Be sure that the connection is on No throttling and not Offline.
This misleading error message seemingly has nothing to do with Chrome or any deprecated functionality. It can have many root causes and seems to occur whenever connectivity can't be established.
I got this while following the React tutorial for Visual Studio Code. In that tutorial you start by creating a template with npx and then running it with npm start. That worked, and I could see that it was using http://localhost:3000 for the URL in the browser.
However, when I changed the code as the tutorial requested and set a breakpoint to debug, I got the error in the OP's post, both with Chrome and with Edge.
Visual Studio Code was creating a default launch.json file for debugging and populating it like this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}"
}
]
}
And I needed to manually change the 8080 to 3000 which fixed the problem.
The key for me was configuring the breakpoint to catch the exception like the OP described (note - you can only configure that with the Debug icon selected in the far left icon menu). While the emitted error message is still the misleading "deprecated" one, there was a message that "the site can't be reached" which you can find if you dig a little - as shown here:
I imagine that practically any configuration issue that causes the connection to fail will cause this error. So firewall issues, missing host program, bad configuration (like mine), etc.
I had the same issue and the problem was with the URL. It was https://localhost:8000; in place of http://localhost:8000.
So try checking your URL and routes.
My server was just not running locally. :) Starting localhost solved it.
For me, the issue was a React/Next.js application was not running.
Basically, you have to keep the application running in a separate window/terminal to be able to attach the debugger. This is unlike the other application where it starts from debug console itself.
In my case, it got resolved by closing the browser and recompiling the app.
Instead of launching your application using the option "Launch Chrome against localhost", rather set your application name for launching - Resolved.
See the attached image for more context.
I had this same error and I resolved it by turning off my plugins. Specifically a CORS plugin I have been using.
Try this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"request": "launch",
"name": "Launch Chrome against localhost",
"type": "dart"
}
]
}
I've tried many of the solutions suggested, and found someplace else this tip that was helpful:
I was unable to reach http://localhost:3000 from npm start run in a react app. So I tried: http://127.0.0.1:3000 and to my surprise it worked!
After some googling, I tried a suggestion to erase my browser cache, so I did it. All cached images and files (Google Chrome) and boom! It worked once again.
I have seen a lot of solutions for this problem, but nothing worked.
After a little debugging and commenting out many parts of the code, I managed to locate the issue.
Basically, it occurs on the backend; not the frontend.
There was an infinite loop that kept responses stuck. Fixing that issue, solved it for me.
I think we should just remove the cookies in that URL:
I displayed a similar message in my debug console and the problem was that the local web server was turned off and therefore unreachable.
I turned on the server in the virtual machine and the app started working again :-)
In my case, I had a Blazor solution and began receiving the "Crbug/1173575, non-JS module files deprecated message". Besides this, I also received a 404 error for the Index.html file!
The cause was that I inadvertently removed the reference in the .Server project to the .Client project. The project compiled fine without the reference, but I guess ASP.NET Core does some sort of reflection-based analysis on the dependencies to dynamically build the route map.
Restoring the reference to the .Client project on the .Server project fixed the problem.
In my case, the problem was because port 4200 was taken by another application (Docker). As soon as I changed the port to 4201 by adding the next structure in the serve section of angular.json file the problem was solved.
"options": {
"port": 4201
}
This may be of use to someone working on a project that communicates across iframes, I found this warning within a current web application: Crbug/1173575, non-JS module files deprecated.
In my case, the reason was that the resource iframe origin wasn't being served meaning the Iframe request URL was not accessible. When serving the resource the warning disappeared.
I had the error crbug/1173575, non-JS module files deprecated with some PDF files displayed in an iframe.
It was because they had a comma (",") in the filename. After renaming the file, everything was OK.
My problem was in the network settings of my Windows 10 computer, not on the browser. I have tried my URL in another computer and mobile browsers, and it was working fine.
So, I have fixed the issue by resetting my network settings
To do that, go to Settings → Network and Internet → Scroll down to Network reset.
Wait for 5 minute until it restarts.
I faced this issue while debugging in Visual Studio Code for an Angular application.
The probable causes may be the server is not up and listening to port. You may start the server manually by ng serve --port with port number. Also compare the URL in launch.json and compare the port number.
In my case it was caused by uBlock Origin. Disabling it on the website promptly fixed the error.
I was adding links to Amazon Affiliate while all of a sudden I faced this error.
To solve it, just stop your adblocker.
To add another angle to this. I named my JavaScript modules with .mjs. After setting my web server to serve mjs with MIME type application/javascript. I got the error
'crbug/1173575, non-JS module files deprecated.'
None of the answers here helped. To fix it I gave a path to the module.
From
<script type="module" src="xxx.mjs"></script>
To
<script type="module" src="./xxx.mjs"></script>
And the error went away.
I ran into this error on three separate Next.js projects. It was the same error in Chrome, Chrome Incognito, Firefox, and Edge.
It happened on a production build (next build && next start) and development server (next dev). After trying a number of fixes – ensuring I was on HTTP, not HTTPS, checking if the port was in use, deleting folder node_modules and running npm install, etc. – the thing that finally worked was restarting my computer...
For aiohttp.
I've stumbled upon this issue with an aiohttp server.
By default it was running on 0.0.0.0:8000 The solution was to change the host and the port to localhost:8080 in main.py file:
web.run_app(app, host='localhost', port=8080)
I had a similar issue. However, I discovered a different solution. It's still worth checking the steps in the GitHub link from the OP’s solution.
The project I was working on was made in an older version, and the launch.json URL had // delimiters. Replacing these with no delimiters resolved the issue.
from
"url":"file:///C://exampleParent//exampleChild//file.txt"
to
"url":"file:///c:/exampleParent/exampleChild/file.txt"
When I try and follow the steps described on Chrome Debugging with Angular CLI, I get a message that the library is no longer supported and a link to this article:
Request’s Past, Present and Future #3142
I had encountered the same problem in Visual Studio Code when I tried to debug a Python file. I resolved it by deleting the previous launch.json file and create a new one for this file.
I had a similar encounter in a JavaScript project. But I hadn’t learned JSON, but I just deleted the last three commands in
the JSON file that is removed the names "url" and "webroot".
I had the same issue with an app that needed to run navigator.geolocation.getCurrentPosition in my React application which of course needs HTTPS.
// .env.local HTTPS is set to true
HTTPS=true
The problem - I was loading the page with HTTP and not HTTPS.
Error Screenshot
Checking point (if you are working with a folder/file)
Check the folder/file name
Remove special characters (the folder/file name does not allow special characters)
Debug you code carefully (Java catch exception can't catch those errors)
I'm following this tutorial Full-stack Redux Tutorial and everything went well till the moment I had to run a local server (Starting under the title "Setting Up a Socket.io Server"). I copied exactly what the tutorial shows and I'm getting this error when running "npm run start"
As seen in the image, the command I'm trying to run is:
babel-node index.js
But the error says nothing I can catch, just that something is wrong with the command, not even with a file.
I'm lost and Google offers little help.
Something else is listening on port 3333 on your machine. Change the port number to something else, and it should work.
If you told us what OS you were using, we could suggest how to determine what is listening on port 3333.
It seems like there's still a connection open on port 3333. If you open cmd and run netstat -a -b you should be able to get a list of open connections together with the executables that started them.
It might be that your Socket.io server previously crashed and the exception wasn't handled properly, possibly leaving the connection open?
I have a Meteor (Node.js) app in production that keeps hanging unexplainably in production. I have put a number of log statements in the code, so I can see that it hangs on a certain method.
My question is if there are any other tools other that the console log that might give me insight into the resource consumption of a Node.js app. Something that might tell me why the app is hanging.
The method on which the server hangs is a method that uses a geocluster and geolib NPM. It usually happens after a method where the Facebook-node-SDK is called.
I am thinking that there might be memory consumption from the calls to the geo npm, or open http connections from the facebook-node-sdk?
Please let me know if there is more information that I can provide. Any help would be appreciated.
You could try node-inspector and pass environment run vars to meteor via NODE_OPTIONS='--debug-brk' meteor run and try your luck there.
(2017 update: there was an answer here referencing Kadira (kadira.io) however this service is no more.. sad).
You may also try the built-in NodeJS devtools available since 6.3. If you read the node-inspector github repo, you can see a blog post referenced there to get started:
https://medium.com/#paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27#.pmqejrn8q
You can try Webstorm, version 9 has meteor support, debugging included.
Ok so I have read through the Socket.IO docs and I am still a little unsure of a couple of points:
The documentation says...
To run the demo, execute the following:
git clone git://github.com/LearnBoost/Socket.IO-node.git socket.io
cd socket.io/example/
sudo node server.js
Now I don't know what this means at all! I think it may be command line interface. I of course have access to this on my localhost, but my online hosting package is a shared LAMP setup. Meaning I don't have access to the root command line (i think).
How do I actually setup socket.IO, is it impossible on my shared server package?
Appreciate any help...
W.
If you aren't familiar with node.js or with basic command line usage then I would suggest that you use a hosted WebSockets solution like pusherapp. Trying to learn WebSockets, and Node.js, and the Linux command line all at once is going to lead to a lot of frustration. Take a look a pusherapp's quick start guide, it's very easy to get started. You can have 5 simultaneous connections with a single application for free (I'm not affiliated with pusherapp).
Updated (with inline answers to questions):
If you are going to go the direction of running a Socket.IO application:
You don't technically need git since you can download node.js and Socket.IO from their respective download links on github.
You don't actually need a LAMP server to use Socket.IO. By default Socket.IO functions as a simple webserver in addition to a WebSockets server. If you want server side scripting then you might want Apache with mod_php, mod_python, etc.
You don't technically need a dedicated server or even root access. You do need a system where you can have long running process. And if you want the service to start automatically when the system is rebooted, you probably want to add a startup file to /etc/init.d, /etc/rc.d which will require root access. Both node.js and Socket.IO can be installed and run from a normal home directory. If you want to run Socket.IO on a standard port like 80 or 443 then you will need to run it with root privilege.
Node.JS scales quite well so Socket.IO will probably scale pretty well too.
It's not a simple matter to get everything setup and working, but if your goal is a free solution for web serving+WebSockets then Socket.IO is probably is good route to at least explore if you are brave.
First you'll have to determine if your host supports SSH. Sometimes they don't by default on shared hosting, but if you ask they can turn it on. If it does you'll use some sort of SSH client to connect to it. Putty for windows is the most common. Then you'll use git, which is a source control program. Which you'll probably have to install on your host, which may or may not be allowed. If you can, this can be accomplished a number of ways, you'll want to read the git documentation, it will depend largely on what linux distribution you're running. CD is change directory, basic command line stuff. sudo on the last line is telling the system to run the command as root, which it will ask you the password for, which you may not have access to on your host. Sounds like you're gonna have an uphill battle on shared hosting. You may want to opt for a VPS instead.
If your shared host is a LAMP system with no command line access you're not going to get very far with Socket.IO. The instructions you posted assume you have command line access and that you've installed the node.js runtime on your system.
If you really want to try this I recommend you get a VPS of your own (I use prgmr.com) to test it out. For what it's worth I found the Socket.IO platform pretty nice to use once I got it up and running.