Nuxt Local Server Gets Stuck

Version
v2.9.2
Reproduction link
https://github.com/sdras
Steps to reproduce
It's a non-deterministic error, so it can be a bit hard to duplicate. There are two main causes of frustration from what I see:

The HMR doesn't really work well, and you'll see an older, cached version of the site, even after restart. I believe this thread is the same issue: https://github.com/nuxt/nuxt.js/issues/5550
Sometimes the local dev server gets stuck- perhaps on a bug, but you are locked out of the app. Also non-deterministic conditions. Sample of this sent to Sebastien. I left the repro link just to my github because it's a project I'm not ready to share publicly yet. I'm extremely low on time so I'm hoping this will suffice. If you really need a public link, I can get you one but it might be a while before I can provide it.

What is expected ?

Server to reflect the changes in the app, especially after restart
Local dev server to load even if there is an error

What is actually happening?

The app gets cached in a particular state. After you restart it, sometimes after as much as 4 times, it works again
The server just keeps reloading and reloading (you just see the loading screen and it starts over). One major problem is that it clears the console as well, so even if it is running into a user error problem, it's hard to track down.

Additional comments?
I've been experiencing this bug since 2.6.*. It happens quite frequently. A few friends have complained to me about it as well. I love Nuxt! I don't want to leave it but my productivity is starting to suffer.

This bug report is available on Nuxt community (#c9797)

Unfortunately I am unable to indicate one specific cause, but while looking into this I found multiple  possible issues. If I read your descriptions to the letter then in some cases they do not fully compare, so there might still be other contributing factors

Webpack does not remove old chunk files after a hot reload, if you set build.devMiddleware.writeToDisk: true in your nuxt.config and check the .nuxt/dist/client folder you will see the old files still being listed.
That doesnt explain why old files are served after a server restart. Only thing I can think off which is persistent after a restart is that both babel-loader as esm are caching files in node_modules/.cache. Possibly one of them believes somehow the old caches are still valid. You could try to remove the node_modules/.cache folder to see if thats the case
Nuxt.js still adds an ETag header in development mode. If you are using a proxy middleware/server then in combination with your browser cache this could maybe also make your browser think the old cache files are still valid. Try to refresh the page with the debug console open and make sure to have ticked Network -> Disable cache (both Chrome as FF).
The referenced issue above could've been a contributing factor after running the dev server for some time. Dont immediately see how it would cause any problems though
If for some reason Nuxt.js is  unable to render your page at all (ie renderRoute returns a falsy value), then the Nuxt Loading Screen will be served instead. Normally this should only happen when webpack is still building, but maybe somehow its also possible that webpack fails silently causing Nuxt.js to be unable to render a page even when the webpack build has finished. If this would occur, then previously the loading screen would be endlessly reloading itself to try to serve your Nuxt.js app which will fail all the time so it'd fallback to the loading screen again. This behaviour should be fixed in @nuxt/loading-screen v1.1.0, it now limits itself to 5 reloads after which it displays an error message. If you manually reload the page it will again limit itself to 5 automatic reloads.
If you are running Node v12 and are debugging some stuff by logging a full VueComponent server side, Node.js contains an issue which causes node to hang
When you soft-kill nuxt (which could mean it keeps running in the background) and start a new nuxt build, then on nuxt start it will detect the port from your config (if you have any) is still blocked by the old process and automatic start listening on a new random port. If you then dont update this port manually in your browser tab, you will still be connecting with the old Nuxt instance instead of the new Nuxt instance
With regards to the console log being cleared, if you load the page in Chrome and enable Preserve log in Settings of the Console tab (gear icon to the right) then all logs should be retained. FF also has a Persists Logs option but in contrast to Chrome this doesn't prevent console.clear calls (the nuxt loading screen calls this).

How does your typical nuxt config look like? Do you extend the webpack config? While working on this it seems similar issues have often been reported to webpack(-dev/hot-middleware).
I dont think we are ready yet to call this issue resolved, the things that I fixed appear to be more effects then causes. But I am not sure where to look anymore as I am unable to reproduce the issues exactly as described.

Hey @pimlie, thank you for all of your time and work on this! Much appreciated. I just added you to the private repo where it's hanging and reloading so you can clone and see as well.
I'm using

Chrome Version 76.0.3809.132 (Official Build) (64-bit)
Mac, I'm on Mojave, MacBook Pro 2018
Node v12.6.0
You can see my nuxt.config.js, I have several plugins: highlightjs custom directive, vue-tags-input, and firebase

I hope that helps track it down. I spoke to two more devs this week who were having the same problem, if you would like, I can ask them if they still have the repos in the stuck state before they bailed if that gives you more information.

Thanks, I tried some stuff on your repo but unfortunately I couldnt get the dev server to hang. Either the work I did wasnt representative to trigger this issue or maybe its just a Mac OS issue.
One Mac OS issue related to webpack watching I came across is this: https://stackoverflow.com/questions/26708205/webpack-watch-isnt-compiling-changed-files. But thats quite old, so no idea if its still an issue at all.
I hate seeing people leave Nuxt.js because of issues like this, but except for trying to get my hands on a mac I'm not sure how to debug this further

I experience this issue as well, and it's starting to be really annoying. The dev server just hangs and does not respond, just a pending request. I do not get any log errors or what so ever, it just does not respond and Chrome is waiting forever. I have not been able to get my server to respond now for more than 30 minutes. Sometimes it works if I restart, sometimes not.

@frellan Could you please share the details of your dev env?
How many open tabs to the dev server do you have? Please check if you can connect to Node from an incognito Chrome window.
If you could record a screencast of when the issue occurs that would be very interesting as well. Am interested to see the contents of both the console as network tab of your browser debug console. Furthermore, please check if Node is busy or not when Chrome is waiting. Does it run at 100% cpu?

It happened to me yesterday but fixed itself after a few minutes. I was able to open it in incognito mode. If I get it again I will report with more info.

@gkkirilov If you are able to open the page in a new incognito window then you have hit the maximum connection limit a browser instance can have to a single domain. I think for FF this is 3 by default and for Chrome 5

Just a heads up: Node.js v12.11.0 fixes the Node.js bug mentioned above. Please give that a try in case you are using Node.js v12.x.

I noticed another issue which could make the dev server appear to be stuck, build errors in dev mode were not shown on the loading screen. That meant the loading screen stayed at 0% progress and the used had to think themselves about maybe looking at the console to see why nothing appears.
Have submitted a pr to change this behaviour so errors during the Nuxt build are also shown on the loading screen: https://github.com/nuxt/nuxt.js/pull/6475

I have had this issue since I started a new project using version 2.10. Sometimes when I inspect the CSS in Chrome, there are no properties. The service worker or socket gets stuck I believe but I am not sure.

I have the same issue as Jake, above. I just updated to Node v12.11.0 and the issue is persisting. I can get it to clear whatever is cached and start updating again in an incognito window most of the time (not always) but then I don't have access to Vue Devtools. Also, the local server still gets stuck even if it's just one tab, it doesn't have to be many/multiple. Hope that helps track things down!

@jake-101 Whats your dev env? Mac, Win/WSL or Linux?
I know this might be asking a bit much but if anyone could record a performance profile when this occurs then that would be helpful. To do so in chrome open the dev console, click on tab Performance and hit record. Once the hanging occurs, try to fix it somehow and once fixed hit stop on the recording. Click on Save profile... (downvote button) to retrieve the profile and please share that.
Otherwise a detailed screencast of when this occurs could also be helpful, for it to be really helpful it would need to show:

error console of developers console (scrolled down to current log)
network tab of developers console (scrolled down to current request)
nuxt console
top command in terminal (or something else that show cpu/memory usage)

@pimlie MacOS. I will try to record the profile and/or do a recording of the error happening in the next couple days.

Thank you @sdras for filing this issue and @pimlie for looking into it.
I've been experiencing this issue multiple times a day for months...and only today decided to finally do something about it and log an issue. Fortunately, it's already been filed here and there are several others experiencing this issue of HMR not working well / consistently.
Here's some additional info that might help. I'm on a mac, using the latest Chrome. Nuxt version 2.x
    "@nuxtjs/auth": "^4.8.2",
    "@nuxtjs/axios": "^5.6.0",
    "@nuxtjs/dotenv": "^1.4.0",
    "@nuxtjs/pwa": "^3.0.0-beta.17",
    "nuxt": "^2.0.0",

Made some changes and it built on the nuxt server (server logs below)
> nuxt --port 3000

   ╭─────────────────────────────────────────────╮
   │                                             │
   │   Nuxt.js v2.9.2                            │
   │   Running in development mode (universal)   │
   │                                             │
   │   Listening on: http://localhost:3000/      │
   │                                             │
   ╰─────────────────────────────────────────────╯

ℹ Preparing project for development                                                                                12:30:47
ℹ Initial build may take a while                                                                                12:30:47
✔ Builder initialized                                                                                12:30:47
✔ Nuxt files generated                                                                                12:30:47

✔ Client
  Compiled successfully in 39.86s

✔ Server
  Compiled successfully in 38.69s

ℹ Waiting for file changes                                                                                12:31:32
ℹ Memory usage: 331 MB (RSS: 520 MB)

But this is what I see in the chrome console:
VM3083:1 GET http://localhost:3000/_nuxt/ab5a9cc2c078b3a3628b.hot-update.json 404 (Not Found)
(anonymous) @ VM3083:1
(anonymous) @ runtime.js:83
hotDownloadManifest @ runtime.js:74
hotCheck @ runtime.js:293
check @ vendors.app.js:15895
push../node_modules/webpack-hot-middleware/process-update.js.module.exports @ vendors.app.js:15860
processMessage @ vendors.app.js:15737
handleMessage @ vendors.app.js:15597
handleMessage @ vendors.app.js:15560
vendors.app.js:12923 warn [HMR] Cannot find update (Full reload needed)
value @ vendors.app.js:12923
value @ vendors.app.js:12923
value @ vendors.app.js:12923
(anonymous) @ vendors.app.js:12923
cb @ vendors.app.js:15869
(anonymous) @ vendors.app.js:15899
Promise.then (async)
check @ vendors.app.js:15898
push../node_modules/webpack-hot-middleware/process-update.js.module.exports @ vendors.app.js:15860
processMessage @ vendors.app.js:15737
handleMessage @ vendors.app.js:15597
handleMessage @ vendors.app.js:15560
vendors.app.js:12923 warn [HMR] (Probably because of restarting the server)
value @ vendors.app.js:12923
value @ vendors.app.js:12923
value @ vendors.app.js:12923
(anonymous) @ vendors.app.js:12923
cb @ vendors.app.js:15870
(anonymous) @ vendors.app.js:15899
Promise.then (async)
check @ vendors.app.js:15898
push../node_modules/webpack-hot-middleware/process-update.js.module.exports @ vendors.app.js:15860
processMessage @ vendors.app.js:15737
handleMessage @ vendors.app.js:15597
handleMessage @ vendors.app.js:15560
vendors.app.js:12923 warn [HMR] Reloading page

The page just sits around forever and spins.

Also just thought of this...a few times when this has happened, I saw a "waiting for socket connection" or similar message. Hope this helps narrow things down..

The waiting for socket connection is probably just caused by the connection limit that Chrome has, you can only connect max 5 times to the same server. Try to open a new incognito tab if this happens or close some open tabs to the dev server if you have them

@sdras @connecteev Thank you for reporting the issue and all the investigation.
I have some guesses, could you try to turn off indicator by build.indicator: false and test ?
I’ll look into it this weekend, sorry for the inconvenience.

I started having this issue earlier today. It occurred on multiple freshly created nuxt projects with very minimal setup (just a config, layout, a page, and one plugin). I've been able to "fix" is twice so far by roughly completing the steps below:

Starting point: nuxt 2.10.1 app, doesn't work (does 5 refreshes and then displays the error message)
Delete buildDir (defaults to .nuxt in the same directory as nuxt.config.js) and node_modules
Change nuxt version to 2.8.0 & npm install
run nuxt &  Test the app on the browser - seems to work!
Stop nuxt
Delete buildDir (defaults to .nuxt in the same directory as nuxt.config.js) and node_modules
Change nuxt version to 2.10.1 (latest version at the time of writing this comment) &  npm install
run nuxt & Test the app on the browser - seems to work! But why?!

Steps

I've done countless clean npm install runs without changing the nuxt version - the issue persisted.
Somehow downgrading the version & upgrading it back up worked for me.  I think it's worth trying if anyone currently has a directory where this issue occurs. I've been testing this with a rather minimal setup meaning that going that many versions back didn't break anything else.
Logically doing such clean installs with different versions shouldn't have an effect as all files and caches are stored in the project's node_modules directory (?). As I stated in the beginning, the trick has worked twice so far. Now I can't seem to be able to re-create the bug anymore with setups that previously triggered it.

It seems to be a problen of cache. I had the same problem, but just running in another port everything works fine, for example npm run dev -- --port 3001

@sdras Through my several days investigation and loads of times debugging, it look like the sever hanging issus it related to chokidar and macOS.
Fortunately, it seemed the issue has been tracked and fixed in https://github.com/fsevents/fsevents/pull/290 , I've verified the fix in my local with latest fsevents.
You could just rebuild your yarn.lock or package-lock.json , nuxt will auto-use the latest chokidar and fsevents

@clarkdo amazing work, mate. The community owes you.
Where's your sponsor/PayPal page? I'd like to buy you a beer or two.

@clarkdo

it look like the sever hanging issus it related to chokidar underlying I/O race condition and macOS.

I've been having this issue on Windows 10.  If the issue reappears I'll try

You could just rebuild your yarn.lock or package-lock.json , nuxt will auto-use the latest chokidar and fsevents

And report back.

Thanks @clarkdo! I will try it out this week and report back. Appreciate your help here.

@Janne252 i guess you are just facing limit of connection to one host. Chrome cant open more than 5 connection to same host, and all new will hang. To verify try to open in another browser when its stuck in chrome or in chrome anonymous tab

@aldarund

i guess you are just facing limit of connection to one host. Chrome cant open more than 5 connection to same host, and all new will hang. To verify try to open in another browser when its stuck in chrome or in chrome anonymous tab

At the time I was googling quite a lot and came across the same suggestion (try another browser). Unfortunately the issue persisted on a Chrome Incognito tab & on Microsoft Edge which suggests the issue was on the build side. If it recurs I'll try other browsers before resetting package-lock.json.

@Janne252 Sorry, I may need to clarify, the fix in fsevents I mentioned above is   macOS only since fsevents is api for MacOS FSEvents, so if your issue is in Windows, it should be some reason else. It would be great that if you can provider a stable producible repo so that we can look into the root cause.

@clarkdo That's what I figured from the description & the original issue on fsevents. Just the similarity & timing of the issue makes it seem like it's the same thing. As I explained in my first comment on this thread; downgrading and upgrading nuxt version weirdly fixed the issue. As if there's some cache outside of local project node_modules directory affected by the nuxt version.
Thanks for all the suggestions. I'll report back if the bug occurs again. Unfortunately it appears to be a rather elusive one on Windows.

Hey, just reporting here that I can confirm it's pretty much a constant when I start the dev server for the first time every morning. I've to manually kill the process and launch again and somehow then it doesn't end up hanging. Windows machine (unfortunately stuck with it)

@theCrius Thanks your the info, but it's kind of hard to guess what the root cause of your issue without further investigation.
Is there any possibility that you can provide a minimal reproducible repo so that we can look into exact issue ?
If it's impossible, could you use chrome tools like https://dev.chromium.org/for-testers/providing-network-details to capture the frontend connection amount, and also dump a CPU profile for node process via  tools like https://nodejs.org/de/docs/guides/debugging-getting-started/#inspector-clients ?

I cannot provide a working repo as the project is a SPA, not so complex but with plenty of components that are strictly working with a backend and set of data coming from an external backend.
In any case, next time I run into this issue I'll run the network details and report back

I was have this issue ~1 month ago on 2.9.x. Interestingly after few days this issue is gone. Then i upgraded to 2.10.x when it is released. As far as i know it is also have a fix for that issue. But as i said, my issue is gone after few days before upgrading 2.10.x. Anyway, this morning this issue is come back. I didnt even ugrade or installed something or change nuxt config. I'm just editing my components.
When i save my component hmr is breaks and when i try to refresh, it is keeps loading.
I'm using Chrome when all of this thing happens. Interestingly, i can view my project on Firefox at the same time Chrome is stuck on loading and hmr is never breaks on Firefox.

I have the same issues. Bug still exist.

Same her @mhajder

I've been having similar issues, it seems that removing the .nuxt folder and restarting the dev server helped getting unstuck.
Perhaps it's a cache issue?

I've been having similar issues, it seems that removing the .nuxt folder and restarting the dev server helped getting unstuck.
Perhaps it's a cache issue?

Yes, that's the only option. But it is in production for me.

Hi all, if you're having similar issue, it would be great if you can provide more details and a reproducible repo, it will help us a lot to find your issue's root cause.
Thanks a lot.

Interestingly this issue is came today completely different. My server stuck during development and when try to restart it give me permission error about .nuxt folder. To remove this folder i had to use third party software. But it didnt help. After first run same error. Cloned my repo to different folder. Everything is fine now.

I have this issue as well. The development experience is really suffering. "Clear site data" is a temporary solution by now. But I'm forced to do it every 10-15 minutes as hot reloading is hanging chrome over and over again

I was have this issue ~1 month ago on 2.9.x. Interestingly after few days this issue is gone. Then i upgraded to 2.10.x when it is released. As far as i know it is also have a fix for that issue. But as i said, my issue is gone after few days before upgrading to 2.10.x. Anyway, this morning this issue is come back. I didnt even ugrade or installed something or change nuxt config. I'm just editing my components.
When i save my component, hmr is breaks and when i try to refresh, it is keeps loading.
I'm using Chrome when all of this things happens. Interestingly, i can view my project on Firefox at the same time Chrome is stuck on loading and hmr is never breaks on Firefox.

Look like my issue in here is about browser. I tested on Chrome Stable and Canary with/without extensions.
Chrome Stable 78.0.3904.108: Stuck after navigating few pages.
Chrome Canary 80.0.3972.0: Doesnt stuck.
Firefox: Doesnt stuck.

I had this issue today and stuck on Firebox developer and Chromium. Both running in another port and removing the node_modules/.cache can fix the problem for me.
Firebox developer | 71.0b11 (64-bit)
Chromium | 78.0.3904.108 (Official Build) Arch Linux (64-bit)
Env: Arch Linux x86_64 , Node v13.1.0, Nuxt 2.10.2

For me, removing @nuxtjs/stylelint-module from my nuxt config allowed my app to build.

Echoing the same issue and resolution:
My client build would never complete (and would keep hot reloading); removing the @nuxtjs/stylelint-module did fix this.

/cc @ricardogobbosouza

Looking more at this, I believe it has something to do with the service worker. That's why when you put it into incognito, it works again. I think something gets b0rked with the service worker that's used for HMR, and it's not able to reconcile the changes. Digging more into this whenever it gets stuck, hoping to find a solution.

@sdras it wasn't working for me even in incognito, as I mentioned in this comment that @nuxtjs/stylelint-module removal worked for me.

For me, removing @nuxtjs/stylelint-module from my nuxt config allowed my app to build.

Interesting, @YuuwakU. I don't think that's everyone's problem, though, because I am not using it, and there are a lot of other people having this issue on a fresh install. 🤔Helpful to know, though!

@sdras yeah, and another observation was that with the create-nuxt-app the package.json versions are weird, for eg, nuxt version will be ^2.0.0 while it will install the latest nuxt version. Even the nuxt module versions are older than the latest stable ones. Haven't checked if this issue has been raised before or not, just thought this piece of information may also be helpful to investigate.

I am also having these issues. A few things I noticed:
This happens more often if more tabs are open. Meaning hot reload has to reload several tabs. Maybe each tab creates a request, and thus somehow hangs.
I also see that Chrome sometimes hangs without even having reported any requests in the network tab.

I was also having this issue, I selected all the linting tools (ESLint, Prettier, Lint staged files, StyleLint) and then when I run yarn dev, I get stuck in the initial loading of Nuxt.
I re-created the project and I selected all the linting tools except for StyleLint option and it worked.

@stevenferrer  True, the same thing happened to me, re-creating the project without stylelint no longer gets stuck when rendering the view of the folder Page. Thank you.

This is all really helpful. :) But I'm not sure we're really going to solve the issue unless we figure out why it's behaving this way, linter or not. Still trying to find the source of the issue, open to more suggestions.

I don't have a stylelint-module. But the issue keeps bugging me

The @nuxtjs/stylelint-module really crashed when there is no configuration file eg stylelint.config.js.
This has been fixed on v3.1.1

I have same issue with: Nuxt 2.10.2, Node: 12.12.0, Typescript: 3.7.2, and using TSX for components and @vue/composition-api with 'vca-jsx' babel plugin. When i change TSX in render function, in console it prints [HMR] bundle rebuilding and then browser refreshes whole app (i guess interupts HMR in the middle).

Has anyone tried just typing rs into the console when it gets slow or stuck? I've found when I am debugging a component and creating lots of HMR updates that have or cause errors it'll slowly start to load slower and slower. A quick rs to restart nodemon has been the quickest and easiest way I've found. works every time without the port getting stuck or other weird issues.

This issue appeared on Windows 10 again after upgrading from nuxt 2.10.2 to 2.11.0.
Following these steps fixed the issue: https://github.com/nuxt/typescript/issues/152#issuecomment-542659708

I managed to solve this by removing: eslint-config-prettier package

Our dev team experienced the same issue. Firefox was loading scripts (I.e. Google Analytics), nuxt loads infinetly and after some time we got a chunk loading failed error in the console. Missed to Screenshot the console and today the issue has not appeared again. We have noticed that behavior multiple times before but a restart of the nuxt server fixed it. Yesterday it reappeared many times when nuxt router was called. We definetly had multiple tabs open, but not sure how many.

I'm able to consistently reproduce this issue on Windows 10. I created a repository with instructions and handy .bat scripts that automate the testing.
The repository can be found at https://github.com/Janne252/issue-reproduction-nuxt-6442
Quick summary of its contents:

install-at-once.bat demonstrates the Failed to show Nuxt.js app after 5 reloads issue.
install-in-series.bat demonstrates a workaround that results in a working development build.

Can confirm, had this issue on my windows machine just now (but not on my mac) and using the install order provided by @Janne252 fixed my local nuxt development server.

Same issue -
The solution that worked for me was:

Shutdown the nuxt server
Restarted the IDE (used the inbuilt terminal in Atom)
Restarted the nuxt server

Worked like a charm!

I have the same issue.
MacOS 10.15.3
Nuxt 2.11.0

Same issue, the only thing to solve it was to change the base url in the nuxt config.
Also, really peculiar, not sure if others are seeing this, but it only happens to me in Chrome.  Even when I stop the servers and delete any dist or .nuxt folders, the browser seems to find the site on my local.
It loads my app but then quickly switches over to the default vue app view when a new project is generated.

I wanted to mention something that may be related to this issue. I was finding my server was hanging when built.  After a process of elimintation, I found the cause was where I had provided a second argument in a middleware:
export default function ({ error, route, store, params }, foo = undefined) {
...
}

I was using this 2nd argument instead of declaring a let foo in the body of the function. By changing this to:
export default function ({ error, route, store, params }) {
  let foo = undefined
}

the issue was resolved

I'm having this issue on one of my development machines, but not the other. Both macOS Catalina. Can confirm it works from an incognito window. But shows an old version of the website in Chrome and Safari. And hangs when you try to reload

restarting OS solved this problem for me. I think some zombie process is getting created on file change

Nice. Restarting did not fix the issue for me.

An issue that may be a gotcha for server deployments (this would potentially be true for developments as well though) is that nuxt will hang if its server side can not access your remote resources via Axios/your ajax client.  I was seeing my demo nuxt deployment hanging in the browser without rhyme or reason until I realised it was only hanging when the server side was trying to make ajax requests.  When I ran a wget on the server hosting nuxt to the same api endpoints, I discovered that requests from the box were hanging because of a local firewall.  Unlike a purely client-side webapp, this is an extra consideration one must make on "Universal" nuxt apps: your nuxt app is its own server and fully capable of performing remote requests as such.

@jaysaurus Thanks, that's useful to know. However, in my case it works fine if I use an incognito browser window. It only fails to dynamically refresh in a normal browser window on 1 of my dev machines (I have 2 macs), the other everything works fine.

Another thought, appreciating that it's a long-shot, are you connecting to remote services that share the same url?
e.g.
remote resoure: 'foo.com/api/bar'
nuxt app: 'foo.com/front-end'
if you have a link marked as '/api/bar' for some reason, nuxt will try to treat it as a route.  I've seen this cause some very weird and sporadic behaviour before.

@jaysaurus No. really not sure why it's happening. I believe it to be something with Chrome caching. Even though I have caching off in the Developer tools. Because I just ran it through the Visual Code Chrome Debugger which launches a different instance of Chrome and it works fine.

Appreciating that I'm clutching at straws (and perhaps for the posterity of future queries): my previous comment counts for serving image sources as well (for example, i have some dynamic image endpoints on my build that will draw stuff like a padlock over an image.  These are served from a grails application on the same address as the nuxt server (managed under-the-hood by a load-balancer, DNS, etc.)  These images can also be served via nuxt's server side ergo, the server must have permission to access remote assets whether for css (e.g. background-image:) or <img src="..." />

Possible answer: https://github.com/nuxt/nuxt.js/issues/6007

Having this issue on Chrome. It takes 15 minutes to reload the page. FireFox/Edge is a different story. I can refresh it all day long. I do not have any more than 2 open tabs at a time and consistently happens using the dev script ("dev": "nuxt"). Running npm run start won't have this issue. Reading the posts above, it's not intermittent like some others have been having. I don't get any issues other than missing map files, no debug output of any kind. Little back story, wrote a VueJS app, saw Nuxt and it's offerings and converted over. Not sure if I'm doing something wrong, but as I said, works in FireFox/Edge just fine.
Microsoft Edge: v44.18362.449.0
FireFox: v76.0.1 (64-bit)
Chrome: v83.0.4103.61 (Official Build) (64-bit)
OS: Windows 10 Pro (v1909 b18363.836)
NPM: v6.14.5
Node: v14.0.0
Nuxt: v2.0.0

Same issue here.
MacOS 10.14.6
Nuxt v2.12.2
Node v12.17.0
Npm 6.14.5.

We simply switched off of Nuxt.
Can't have this kind of behaviour when you are developing application for production.

@ImSeaWorld If you dont have issues with nuxt start then its most likely related to the often mentioned limit of ~5 connections by your browser to the same domain. You can confirm this next time by starting a private/incognito session for your browser and try to connect.
@theCrius Thats sad too hear. Unfortunately it seems we just cannot reproduce this issue reliably and up to now nobody in this thread has been able to help us to make a reliable reproduction.
To summarize the state of this issue:

There is/was an fs-events bug on MacOS thats causing this: see this comment
If this only happens in dev mode its likely related due to the connection limit

:heavy_check_mark: Start a new private/incognito browser session to verify this

Reproduction needed
At this moment we don't have any reason to believe there is more to this issue then the above two things. But I would be happy to be proven wrong, if anyone can create a reliable reproduction then please do. I might be a bit cocky here but if people stop using Nuxt.js because of this I assume it shouldn't be that hard to make a reproduction?

@pimlie ~5 limit connection is a false clue. I've experienced this issue with a freshly started computer and just a chrome tab open to the localhost's port of the application. The thing that made us simply abandon adoption is that the issue is clearly windows focused (meaning chrome on windows, or the windows os itself) but when none of the reported had the ability to branch out and investigate or resolve the issue, there are not hint of the core dev team attempting to check on it.
Nuxt sell itself as a production ready framework for Vue, possibly the "main" one but if the core dev team is not willing to invest some time in resolving a bug like this, there is little trust to be have that they will do it in the future when other issues will arise that are not easily reproducible in their "expected" environment.
Not everyone in the industry use fancy mac or much more reliable linux machines. Some have to deal with company policy the demand a windows machine, as unfortunate as it is.

@theCrius Let me emphasize to make it clear:
I am in all ways thinkable sustaining the claim that Nuxt.js is production ready
And I do not think that your message is fair to anyone who has contributed to the Nuxt.js ecosystem. If you look back in to this issue you will see I have already spent 2+ full days on this issue and I know @clarkdo has too.
But lets not fall into a discussion about semantics, let me emphasize another thing that I cannot stress enough:
:grey_exclamation: Help us to help you
What do I mean with that? One simple thing: create a reliable reproduction including any hardware or software requirements that describes step-by-step when the issue happens.
We are all developers here, so you should know exactly the type of information that another developer needs to debug / resolve an issue. Unfortunately nobody I work with on a day to day basis is experiencing these issues, so this means I cannot investigate this myself. The @nuxt/core-team doesn't have a magic crystal ball we can look into to know what is causing an issue. So we need your help with that.
Open source is not about being free but about being able to collaborate on the project. To work together to improve the software which we all benefit from.

Thanks for your work so far here, we all appreciate your time.
I did add you to a repo where I could reproduce the problem, and others could too when they cloned it, and I'm not sure there was any followup there. As I mentioned to you in person, I'm working on tracking it down when I can as well, but have limited time at the moment.

@sdras Could I get added to the repo? Would save me time :)

Absolutely, let me go find it and I'll add you.

Thanks @sdras, also really appreciate the time you invested in this issue. As mentioned at the time I couldn't reproduce the error myself with your repo although I did found some other issues related to the loading screen with could contribute to it. But @clarkdo did and found that fs-events issue which should be resolved by now.

@pimlie is right, if he can't reproduce, it's up to us who can to track down the issue. Let's all try to dig a little deeper than "I deleted this, it's gone" and question why that happened, because even the file and library deletion hasn't seemed to be that deterministic either.
I actually haven't personally seen an occurance of this in the past few months, but I'll try to set aside time next time I do.

Open source is not about being free but about being able to collaborate on the project. To work together to improve the software which we all benefit from.

I knew I was going to trigger someone with that comment. I know full well that open source is not "free stuff boys!" and whoever manage to work on a project with thousands (and more) adoption have all my respect, if nothing for just the clear skills they have that are far superior to mine.
About the reproduction, it's a nice fable that 90% of the time, is used to not have to deal with an issue as, unless someone is doing some hobby project, the repo to provide would be something used by a company and, of course, sharing that is not really possible the vast majority of time.
And, if someone was just doing a side project, I can assure you he will just switch library over the weekend and not bother having to deal with this.
In the 86 comments here, surely there is enough to start to understand at least where to look for. First thing I would have done is set up a windows crappy laptop or vm and have a script keep launching the server, try to connect and if succeed, shut it down and start again.
I could do it myself but apart from that, I wouldn't know where to look for in case I find an occurrence of the issue which is, apparently, random (and we know there is no such thing as this).
As much as there is absolutely no ground to demand anything at all from the core dev team of an open source free project, there is also the more than valid response of being disappointed when you adopt it because it claims to be a stable production ready solution, saves having this issues.
If we, who are no ones really, decided to just drop it, you can be sure it's not just for this specific issue.
My previous message was indeed maybe a bit strong as I let my emotions get the better of me, I apologize if anyone was offended by that
Unfortunately if you are sure you are not hitting the connection limit of your browser but Nuxt still apears stuck, then the message stays mostly the same.
If you can reproduce this stuck behaviour locally but are unable to create a reproduction that works reliably, feel free to contact me on discord if you want to pair up debugging it
With regards to the connection limit issue, that is being addressed in #7286 by @pi0. You can watch that PR to be notified about updates.

My server was stuck and I updated this issue. I have just started a new project and it wasnt working. I was using node version 10.14.0 and it wasn't working. I updated my node version to 12.17.0 which is the most up-to-date one now and hot reloading is working fine.
Curious to see what results are people seeing if they change their node version

@theCrius Yeah, you got me.
My previous message was indeed maybe a bit strong as I let my emotions get the better of me, I apologize if anyone was offended by that
Unfortunately if you are sure you are not hitting the connection limit of your browser but Nuxt still apears stuck, then the message stays mostly the same.
If you can reproduce this stuck behaviour locally but are unable to create a reproduction that works reliably, feel free to contact me on discord if you want to pair up debugging it

It's all good @pimlie, we are humans and I know full well how pretentious some people are towards free open source projects so I fully expect someone to react the way you did. No hard feeling here.
The company I work for dropped nuxt but that doesn't mean I did. We are in the middle of quite complicated times now and things are frenetic more often than not. When I'll get back some more free time, I'll definitely try to use nuxt for some small personal projects and see if I run in this weird behaviour again, even if my personal pc run a linux distro so, I don't really know.
Hope others will manage to provide some more insight over time and this damn issue is resolved once and for all.
Have a good week :)

I recently started hitting this issue myself with a  new nuxt project (create-nuxt-app). HMR broke immediately / refreshing the browser hangs. I am aware of the 5 tab connection limit but it wasn't this. The only thing which fixed it (not even an OS restart) was unregistering the nuxt service worker (which I believe is from the @nuxtjs/pwa module). Funnily enough, the broken project didn't have the pwa module installed - it was from a different local Nuxt app.
This fixed it for me:

type: about:debugging#workers in the address bar (firefox) or chrome://inspect/#service-workers in chrome
find the nuxt service worker for the current port of your app:

Click unregister firefox or terminate in chrome. In Firefox, even if the icon is not green, still click unregister
Kill the nuxt app / relaunch it / restart your browser

result: HMR works perfectly again.
I suspect there are multiple ways HMR gets stuck and this is only one of them. But for what it's worth, I've never had a problem with Nuxt HMR - and it only started misbehaving when I started switching between multiple nuxt projects more (with different setups - SPA/Universal/Universal + PWA).
Some logs:
08:20:33.583 Failed to load ‘http://localhost:3000/__webpack_hmr/client’. A ServiceWorker intercepted the request and encountered an unexpected error. workbox-routing.prod.js:1:868
08:20:33.583 The connection to http://localhost:3000/__webpack_hmr/client was interrupted while the page was loading. vendors.app.js line 270 > eval:88:13
08:20:33.583 Firefox can’t establish a connection to the server at http://localhost:3000/_loading/sse. app.js line 323 > eval:103:17
08:20:33.584 Error: Manifest request to /_nuxt/8d270078ac8fe24b9be8.hot-update.json timed out. runtime.js:92:16
08:24:27.692 Firefox can’t establish a connection to the server at http://localhost:3000/__webpack_hmr/client. vendors.app.js line 270 > eval:88:13

I hope that helps someone!

I have this issue on 10.14.6
It just happens randomly and the server stops responding; have to restart the server before it works again.

This looks relevant:
https://github.com/vercel/next.js/issues/10061#issuecomment-632077342

I also had this issue. I develop a Nuxt app which is also used in production. Locally I develop on macOS and I was using the 2.11.0 version of NuxtJS in a Docker environment with a base image using node:12.17.0-alpine3.9.
I have updated the Node version to node:13.14.0-alpine3.11, but I had to roll the Nuxt version back to 2.9.0 in order to resolve this issue. I have tested the app in dev and prod mode and it's working without issues.
Currently, the latest version of Nuxt is 12.13.0, but the issue still persists with that version.

Only happens when i have the local app open in more than one tab.

I know this might be asking a bit much but if anyone could record a performance profile when this occurs then that would be helpful. To do so in chrome open the dev console, click on tab Performance and hit record. Once the hanging occurs, try to fix it somehow and once fixed hit stop on the recording. Click on Save profile... (downvote button) to retrieve the profile and please share that.
Otherwise a detailed screencast of when this occurs could also be helpful, for it to be really helpful it would need to show:

error console of developers console (scrolled down to current log)
network tab of developers console (scrolled down to current request)
nuxt console
top command in terminal (or something else that show cpu/memory usage)

@pimlie I still experience this issue fairly regularly and managed to record a performance profile. Would it still be helpful for me to share it at this stage or have we moved on from there in the investigation?

I fixed this by setting baseUrl for axios in nuxt.config.ts.

I ran into the same issue (haven’t read the whole thread yet), but in my case it’s only a Chrome issue, and everything works fine on e.g. Firefox.

Same here, works fine in Safari but hangs on third route navigation in Chrome 🤔

When loading the page , you can find "establishing secure connection" in status bar (the left bottom corner).
Because of this, make a change here :
1.input "chrome://flags/" in the address bar, hit enter.
2.find "Allow invalid certificates for resources loaded from localhost", change it to "enabled".
Everything works fine for me.

This thread reminds me of Superstition in the Pigeon 😄

It's crazy that this is still in issue. Tried almost anything listed here. Nothing works. M1 Mac Air.

Don’t know if it helps, but for me it was an issue with multiple open tabs.
As long as there’s just a couple, everything works fine.
Вт, 28 дек. 2021 г. в 21:15, MurmeltierS @.***>:

It's crazy that this is still an issue. Tried almost anything listed here.
Nothing works. M1 Mac Air.
—
Reply to this email directly, view it on GitHub
https://github.com/nuxt/nuxt.js/issues/6442#issuecomment-1002226327, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABN6JIAXF5D723JEKX4DDDUTH5FPANCNFSM4IYR2XJA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: <nuxt/nuxt.
@.***>

I've had this problem on Windows 10. I just changed my port and it worked for me.
npm run dev -- --port 3001

I had this problem on Windows 10 and I had to just to close my IDE and run it again as  administrator. My IDE is VS Code.

Had this problem too on VS Code - Windows 10.
But I found I was trying to run npm run dev command on a wsl Terminal which was working by the way, but stayin cached and not updating on saves.
As soon as I run the command on a powershell or git bash terminal, the problem got fixed.
I also added this to my nuxt.config.js:
   watchers: {     webpack: {       aggregateTimeout: 300,       poll: 1000     }   }
Hope this helps.
Cheers
Sam.

I swear this thread is just a gallery of heisenbugs, full of accidental "fixes" that work for a subset of people, and (most likely) tengentially reset the actual buggy bits. Meanwhile, there's noone from the developers looking at this, because everyone is (most likely) working on making Nuxt 3 happen. Can we get an official maintainer eyeball on this? :)

I've had similar problems to this on nuxt3  😂
I just run into issues where there's no errors and I can't figure out what package / component broke my build.

to @davidawad
For real? Is there a long pending HMR request?
Would be weird, considering that Nuxt 3 is supposedly rewritten from scratch.

For me the issue seems to be related to Nuxt Auth (auth-next 5.0.0 in my case, I didn't test the older stable version). As soon as I removed the auth module from my nuxt.config.js everthing started working fine again.

I had to to comment out the devtool: 'source-map' from my nuxt.config.js to solve the issue.

I have no solution for this till the date, the socket seems to be stopped working, hot reloading is not working properly

Sometimes Nuxt will hang out and keep loading and present a blank screen if you have more than 1 or 2 browser pages pointing to your app. Closing them and leaving only one seems to fix the issue.

Precisely
Вт, 17 мая 2022 г. в 21:46, victor-adrian @.***>:

Sometimes Nuxt will hang out and keep loading and present a blank screen
if you have more than 1 or 2 browser pages pointing to your app. Closing
them and leaving only one seems to fix the issue.
—
Reply to this email directly, view it on GitHub
https://github.com/nuxt/nuxt.js/issues/6442#issuecomment-1129202553, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABN6JNHFXKZHE7EXBODA2LVKPSQZANCNFSM4IYR2XJA
.
You are receiving this because you commented.Message ID: <nuxt/nuxt.
@.***>

Hi guys, is there an official fix to this issue?

For me the problem was that I had another app running via docker on port 3000.
instead of throwing an error, the endpoint would just not respond. just make sure you do not have any other app running on port 3000 or the port is blocked otherwise.

@oshell You cannot run two apps on the same port. In your case you just were trying to open your other app that was up in 3000, while the Nuxt one was up on some other random port, I think. :thinking:

Just a heads up: Node.js v12.11.0 fixes the Node.js bug mentioned above. Please give that a try in case you are using Node.js v12.x.

Yup, upgrading from node 12.0 to node 12.22.12 fixed it for me.

The waiting for socket connection is probably just caused by the connection limit that Chrome has, you can only connect max 5 times to the same server. Try to open a new incognito tab if this happens or close some open tabs to the dev server if you have them

This works for me, thank you!

I'm having an issue accesssing a webpage with RSelenium. I think it might be due to something like this (although I could be very wrong because I know next to nothing about nuxt). Details below. Basically, I can access the webpage (built with nuxt I think) fine myself, but if I try to access it with RSelenium, there is just a spinning loading circle forever. If anyone has any suggestions I would greatly appreciate it. The webpage is https://cear.tuftsmedicalcenter.org/registry/methods/5089
You can replicate it like this, if you have R and RSelenium set up:
library(RSelenium)
browser = remoteDriver(port = 4445)
browser$open()
browser$navigate("https://cear.tuftsmedicalcenter.org/registry/methods/5089")
io = file("output.html")
writeLines(browser$getPageSource()[[1]], io)
close(io)
browser$close()

The sourcecode of the page it takes me to is:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" data-n-head="%7B%22lang%22:%7B%221%22:%22en%22%7D%7D">

<head>
  <title>Tufts CEA - Tufts CEA</title>
  <meta charset="utf-8" data-n-head="1" />
  <meta content="width=device-width,initial-scale=1" name="viewport" data-n-head="1" />
  <meta content="" name="description" data-hid="description" data-n-head="1" />
  <link href="/favicon.ico" type="image/x-icon" rel="icon" data-n-head="1" />
  <link href="https://use.typekit.net/rhz2swc.css" rel="stylesheet" data-n-head="1" />
  <link href="https://fonts.googleapis.com/css?family=canada-type-gibson:100,300,400,500,700,900&display=swap"
    type="text/css" rel="stylesheet" data-n-head="1" />
  <link as="script" href="/_nuxt/3a37233.js" rel="preload" />
  <link as="script" href="/_nuxt/fc025f1.js" rel="preload" />
  <link as="script" href="/_nuxt/358a0d4.js" rel="preload" />
  <link as="script" href="/_nuxt/9070c62.js" rel="preload" />
</head>

<body>
  <div id="__nuxt">
    <style>
      #nuxt-loading {
        background: #fff;
        visibility: hidden;
        opacity: 0;
        position: absolute;
        left: 0;
        right: 0;
        top: 0;
        bottom: 0;
        display: flex;
        justify-content: center;
        align-items: center;
        flex-direction: column;
        animation: nuxtLoadingIn 10s ease;
        -webkit-animation: nuxtLoadingIn 10s ease;
        animation-fill-mode: forwards;
        overflow: hidden
      }

      @keyframes nuxtLoadingIn {
        0% {
          visibility: hidden;
          opacity: 0
        }

        20% {
          visibility: visible;
          opacity: 0
        }

        100% {
          visibility: visible;
          opacity: 1
        }
      }

      @-webkit-keyframes nuxtLoadingIn {
        0% {
          visibility: hidden;
          opacity: 0
        }

        20% {
          visibility: visible;
          opacity: 0
        }

        100% {
          visibility: visible;
          opacity: 1
        }
      }

      #nuxt-loading>
      div,
      #nuxt-loading>

      div:after {
        border-radius: 50%;
        width: 5rem;
        height: 5rem
      }

      #nuxt-loading>

      div {
        font-size: 10px;
        position: relative;
        text-indent: -9999em;
        border: .5rem solid #f5f5f5;
        border-left: .5rem solid #000;
        -webkit-transform: translateZ(0);
        -ms-transform: translateZ(0);
        transform: translateZ(0);
        -webkit-animation: nuxtLoading 1.1s infinite linear;
        animation: nuxtLoading 1.1s infinite linear
      }

      #nuxt-loading.error>

      div {
        border-left: .5rem solid #ff4500;
        animation-duration: 5s
      }

      @-webkit-keyframes nuxtLoading {
        0% {
          -webkit-transform: rotate(0);
          transform: rotate(0)
        }

        100% {
          -webkit-transform: rotate(360deg);
          transform: rotate(360deg)
        }
      }

      @keyframes nuxtLoading {
        0% {
          -webkit-transform: rotate(0);
          transform: rotate(0)
        }

        100% {
          -webkit-transform: rotate(360deg);
          transform: rotate(360deg)
        }
      }
    </style>
    <script>window.addEventListener("error", function () { var e = document.getElementById("nuxt-loading"); e & amp;& amp; (e.className += " error") })</script>
    <div role="status" aria-live="polite" id="nuxt-loading" class=" error">
      <div>Loading...</div>
    </div>
  </div>
  <script>window.__NUXT__ = { config: {} }</script>
  <script src="/_nuxt/3a37233.js"></script>
  <script src="/_nuxt/fc025f1.js"></script>
  <script src="/_nuxt/358a0d4.js"></script>
  <script src="/_nuxt/9070c62.js"></script>

</body>

</html>

Here are the browser warnings in case that's helpful.
[[1]]
[[1]]$level
[1] "WARNING"

[[1]]$message
[1] "Trying to re-register CID '{e26dbdcd-d3ba-4ded-88c3-6cb07ee3e9e0}' already registered by<EMAIL_ADDRESS>
[[1]]$timestamp
[1] 1.66476e+12

[[2]]
[[2]]$level
[1] "WARNING"

[[2]]$message
[1] "Only application manifests may use the 'binary-component' directive."

[[2]]$timestamp
[1] 1.66476e+12

[[3]]
[[3]]$level
[1] "WARNING"

[[3]]$message
[1] "Unknown property 'grid-auto-columns'.  Declaration dropped."

[[3]]$timestamp
[1] 1.66476e+12

[[4]]
[[4]]$level
[1] "WARNING"

[[4]]$message
[1] "Unknown property 'grid-auto-rows'.  Declaration dropped."

[[4]]$timestamp
[1] 1.66476e+12

[[5]]
[[5]]$level
[1] "WARNING"

[[5]]$message
[1] "Unknown property 'grid-auto-flow'.  Declaration dropped."

[[5]]$timestamp
[1] 1.66476e+12

[[6]]
[[6]]$level
[1] "WARNING"

[[6]]$message
[1] "Unknown property 'grid-column-gap'.  Declaration dropped."

[[6]]$timestamp
[1] 1.66476e+12

[[7]]
[[7]]$level
[1] "WARNING"

[[7]]$message
[1] "Unknown property 'grid-row-gap'.  Declaration dropped."

[[7]]$timestamp
[1] 1.66476e+12

[[8]]
[[8]]$level
[1] "WARNING"

[[8]]$message
[1] "Unknown property 'grid-template-areas'.  Declaration dropped."

[[8]]$timestamp
[1] 1.66476e+12

[[9]]
[[9]]$level
[1] "WARNING"

[[9]]$message
[1] "Unknown property 'grid-template-columns'.  Declaration dropped."

[[9]]$timestamp
[1] 1.66476e+12

[[10]]
[[10]]$level
[1] "WARNING"

[[10]]$message
[1] "Unknown property 'grid-template-rows'.  Declaration dropped."

[[10]]$timestamp
[1] 1.66476e+12

[[11]]
[[11]]$level
[1] "WARNING"

[[11]]$message
[1] "Strict-Transport-Security: The connection to the site is untrustworthy, so the specified header was ignored."

[[11]]$timestamp
[1] 1.66476e+12

[[12]]
[[12]]$level
[1] "WARNING"

[[12]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[12]]$timestamp
[1] 1.66476e+12

[[13]]
[[13]]$level
[1] "WARNING"

[[13]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[13]]$timestamp
[1] 1.66476e+12

[[14]]
[[14]]$level
[1] "WARNING"

[[14]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[14]]$timestamp
[1] 1.66476e+12

[[15]]
[[15]]$level
[1] "WARNING"

[[15]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[15]]$timestamp
[1] 1.66476e+12

[[16]]
[[16]]$level
[1] "WARNING"

[[16]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[16]]$timestamp
[1] 1.66476e+12

[[17]]
[[17]]$level
[1] "WARNING"

[[17]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[17]]$timestamp
[1] 1.66476e+12

[[18]]
[[18]]$level
[1] "WARNING"

[[18]]$message
[1] "Unknown descriptor 'font-display' in @font-face rule.  Skipped to next declaration."

[[18]]$timestamp
[1] 1.66476e+12

[[19]]
[[19]]$level
[1] "SEVERE"

[[19]]$message
[1] "SyntaxError: invalid property id"

[[19]]$timestamp
[1] 1.66476e+12

Switched to using the python selenium wrapper and it's working fine. Might just be an RSelenium issue

When loading the page , you can find "establishing secure connection" in status bar (the left bottom corner). Because of this, make a change here : 1.input "chrome://flags/" in the address bar, hit enter. 2.input "secure" in the search flags, find "Allow invalid certificates for resources loaded from localhost", change it to "enabled". Everything works fine for me.

Thank you !

I have a similar problem, my Nuxt v2.17.1 project, when opening it from Chrome it stays loading (loading spinner appears), and it takes 3 to 15 seconds to fully load the application. I have SSR disabled. In incognito and guest mode it doesn't happen and in other browsers.
My version of Node.js v16.16.0
I actually create a whole new project from scratch, and the same thing happens, the Loading spinner appears.
I have uninstalled and reinstalled Chrome several times from scratch (even older versions), I have even deleted the keys that the browser generates in regedit but the problem persists.
In my nuxt.config.js I set the value loading in 'false' and it still shows up.
I tried on another computer and the load is immediate, the spinner not shown. So this "bug" is something strange.
I tried changing the localhost port and nothing.
I tried with Postman and the response is immediate, the only drawback is with Chrome.

I have a similar problem, my Nuxt v2.17.1 project, when I open it from Chrome it stays loading (load spinner appears), and it takes 3-15 seconds to fully load the app. I have SSR disabled. In incognito and guest mode this does not happen or in other browsers. It is worth mentioning that I have no extensions installed. I tried over and over again clearing cache and all browser data but the same thing keeps happening.
My version of Node.js v16.16.0
In fact, I create a whole new project from scratch and the same thing happens: I get the Loading spinner.
I have uninstalled and reinstalled Chrome several times from scratch (even older versions), I have even removed the keys that the browser generates in regedit but the problem persists.
In my nuxt.config.js I set the load value to 'false' and it still shows up.
I tried on another computer and the load is immediate, the spinner is not shown. So this "error" is kind of weird.
I tried changing the localhost port and nothing.
I tried with Postman and the response is immediate, the only drawback is with Chrome.

Have same issue, page loading around 15 seconds on Chrome and Edge, on FF works fine
Tried incognito, other ports, nothing works
Nuxt v3.6+
Node.js v16.20.0

If you're encountering an issue like this, please open a new issue with a reproduction. This is an old Nuxt 2 issue and not related to Nuxt 3.


CaptivePortal: Option to set voucher codes manually invalid

It's possible to add an option like in the old CP to set vouchercodes manually invalid?

hey @AdSchellevis nice! But can you add this option also to the "Captive Portal Sessions" Overview page?
So it's easier to cancel an active session.

@DokuKaefer sorry, can't do that. glueing sessions back to the authenticator they belong to and fixing the UI involves quite some work which I don't have the time for.


AudioFeatures return type

I just discovered that the documentation of the spotify api is not quite correct concerning the 'Get Several Tracks' Audio Features'. Namely, the returned result can contain null values when there are no audio features for a certain track.
This can easily be fixed by changing the return type to an Option<_>.
Be aware that the way I changed it is non-backwards compatible, so it's probably not good to merge it blindly. I still wanted to let you know and point out the necessary change. An easy way to make it backwards compatible is to add a new function which returns the correct result.

Funny you mention that, I've realised it too quite a while ago. In the rewrite I first filtered null values out and then changed the field to a Vec<Option>. I'm still not sure how to proceed with this, as Vec<Option> is not as nice to use, but it's more transparent than filtering out the null values.
So I take it you think using an Option is the best way? Thanks for the pull request, by the way. I'll merge it into the rewrite branch once I tidy it up a bit and release it on GitHub.

Yes, I'd argue for going the Option<> route.
The way I use it atm it doesn't matter if null values are filtered, but I'm planing on a different way to use the result in which it will be very important to know which ones are null.
It's very easy to get the filtered version if you have a vec of options by simply doing a filter map like this:
vec.iter().filter_map(|obj| obj?).collect()
This transforms a vector of options into a vector of all 'Some' values, effectively filtering out the null values from the api result.
I'd say this is convenient enough, but of course, you could provide two seperate functions if you think the use of the filtered result is important enough :)

I see, thanks for the input and the PR!I'll go the Vec<Option> route then. I'll also try to release the rewrite to GitHub soon and merge the PR!

Btw, why haven't you pushed your current progress of the rewrite on a seperate branch?
Just curious :)

At first I thought I'd just release it directly but I'd rather publish something usable even though it's not perfect and make a few breaking changes on that branch possibly. And I haven't done that yet because it's messy, there are lots of "stupid" todos and comments haha

next was just published. I'll deal with this PR later!

So, to recap, I added it to next myself when rewriting. If it's fine with you I'll just close this PR.


Setting default value for quick filter causes double grid population

Hi Volkan,
Your framework is great - it's really time saver, works quite smoothly and is looking great!
Could you let us know if this is a bug or just my incorrect usage of the feature.
I tried to set default value using init for quick filter, directly setting value after locating quick filter but both cases result into duplicated population of the grid. All this was done according to your guides and samples in grid.ts - tried both places getQuickFilters and createQuickFilters.
If I'm setting value directly then it immediately populates the grid as change event is triggered in such case and then one more population on initialPopulate().
On other side If I declare init handler for the quick filter then the handler is called somewhere after initialPopulate() and results in second populate as well.
This was tracked by SQL profiler and it showed this issue constantly. Also I debugged java script but haven't found the appropriate way. The only thing that might work is populateLock/populateUnlock but I don't want to call them separately in different events as it might result in broken behavior when populateUnlock is not executed due to some reasons.
As a side note - I've implemented field level permissions behavior and can contribute it to the project - just let me know if this is needed and where to continue with this separate topic.

It is due to use of change event, plus async nature of initialization. Tried to fix it 2.5.6 by changing initial populate to use timeout, hope won't create a side effect.

Thank you for prompt reply and quick fix!
Will try tomorrow if this helps.
By the way, alternatively you could lock grid population at the beginning of constructor and then unlock in the end of it (in try/finally block)? Or maybe this will also be problematical due to async nature of initialization?

It seems the issue has been fixed in 2.5.6! But I rolled back to 2.4.10 as there is some another issue added since this version. Namely, grid is not expanding now to full area size. It just expanded in horizontal direction properly - vertical (height) is not expanded.

Check the upgrade guide

Thank you a lot!!!


Settings page for notifications

See: https://next-console.couchershq.org/notifications
This should be brought into the web frontend.

If we can get this in the Phase 3 milestone (pre-newsletter), that'd be great!


why is the code not same as the paper

in the paper, you said the sem would get through  1D Convolution with non-linear operation to the ins,  and as it did in the code. However, the output of the net work has size of  Bn13 and the ins have the size of bn5. i wonder Why is the output the opposite between ins and sem. i always thought the sem means the 13.

@MrCrazyCrab The instance features and semantic features have the same dimension 128 (e.g. 24 x 4096 x 128). At last, we apply a 1D convolution to the instance features for generating the instance embeddings (B x N x 128 --> B x N x 5).  Similarly, we obtain the semantic feature matrices (B x N x 128 --> B x N x 13) by a 1D convolution. The description in the paper is consistent with the code.

@dlinzhao i konw what's you meaning, just a little confuse. Pardon for my ignorance， i thing your idea is the same as ASIS, but i met some problem in your code. When i train the model, i found the the label of seg is only 0 or 1 after 1 epoch, which would not happen in ASIS. I I have tested the two algorithms using the same data,  so is there anything wrong?
looking for your reply!

 From the output information, the sem_loss and disc_loss are correct, but the total loss is Nan. So you can check the calculation of total Loss or use the training pipeline in JSNet.

i don't think the sem_loss and disc_loss are correct. The output of train phase label is invalid. Is it only in the later epoch that the network would get label right?

I mean there is no numerical error (e.g. Nan or Inf) for the sem_loss and disc_loss. The total loss is Nan causing the network to fail to output correct predicting labels.

@dlinzhao  for the loss, i found that the nan is comes from myself designed loss function. And i comment my loss function, the logs is as follows:
Namespace(batch_size=3, decay_rate=0.7, decay_step=200000, gpu=0, input_list='ins_val.txt', learning_rate=0.001, log_dir='logs', max_epoch=1000, momentum=0.9, num_point=4096, optimizer='adam', restore_model='log_01')
Fail to load pre_modelfile: log_01
**** EPOCH 000 ****
2020-11-16 17:13:30.147359
loss: 34.298; sem_loss: 3.457; disc_loss: 30.840; correct: 0.037109; total_IoU:0.018905.
loss: 10.657; sem_loss: 1.663; disc_loss: 8.994; correct: 0.094529; total_IoU:0.049609.
loss: 9.801; sem_loss: 0.809; disc_loss: 8.991; correct: 0.112574; total_IoU:0.059644.
accuracy: 0.117682
mean loss: 10.984212
one epoch time: 32.3599
**** EPOCH 001 ****
2020-11-16 17:14:02.507317
loss: 9.772; sem_loss: 0.793; disc_loss: 8.979; correct: 0.245036; total_IoU:0.139624.
but the label is still have two, the pred is invalid.

At least the current total loss is normal (not Nan and Inf). You can test it after more training epoch.


Prod bucket should be named cellxgene-dataset-submissions without env specification at the end

We need to change the bucket name so that the prod bucket doesn't have -prod in its name. PR already created.

@metakuni just approve the PR pls


Why are while-loops much slower than for-loops?

I ran the following snippet at https://dartpad.dev and the for-loops are always 1.75 times faster than the while-loops. Why is that?
void main() {
  final n = 1e9, loops = [
    () {
      int j;
      for (int i = 0; i < n; i++) {
        j = 5;
        j *= calculation(j);
      }
    },
    () {
      for (int i = 0; i < n; i++) {
        int j = 5;
        j *= calculation(j);
      }
    },
    () {
      int i = 0;
      while (i++ < n) {
        int j = 5;
        j *= calculation(j);
      }
    },
    () {
      int i = 0, j;
      while (i++ < n) {
        j = 5;
        j *= calculation(j);
      }
    },
  ];

  for (int i = 0; i < loops.length; i++) {
    final time = DateTime.now();
    loops[i]();
    print('Loop ${i + 1}: ${DateTime.now().difference(time).inMilliseconds}ms');
  }
}

int calculation(int n) => n * n ~/ n;

I tested this in an attempt to finding answers to https://github.com/dart-lang/sdk/issues/39006.

Below you can find some analysis of the difference you are seeing. However I would like to discourage you from looking at performance in such a way: micro-optimizing your code by using for or while based on some microbenchmarks is rarely (if ever) needed.
First of all, I would like to bring to your attention the fact that when you run things in DartPad it compiles Dart to JavaScript, which is then run inside your browser - so this is not going to answer any questions about Dart performance in the context of Flutter - because this would have drastically different performance characteristics from running Dart using its native AOT compiler. Also this introduces a lot of points where things can go slightly wrong.
Now the code produced from while and for loops by dart2js is somewhat different. for loop benchmark gets compiled to this (dart2js -O3 --no-minify):
  V.main_closure.prototype = {
    call$0: function() {
      var t1, i;
      for (t1 = this.n, i = 0; i < t1; ++i)
        ;
    }
  };

while while-loop benchmark gets compiled to something like this
  V.main_closure2.prototype = {
    call$0: function() {
      var t1, i, i0;
      for (t1 = this.n, i = 0; i0 = i + 1, i < t1; i = i0)
        ;
    }
  };

The code is slightly different (there is one more live variable) - this probably leads to slightly different performance (especially in different browsers). Note that additional live variable appears because you use post increment which returns the previous value of i - if you want your while and for loops to make exactly the same number of iterations you should have written it as ++i < n - which would also eliminate temporary variable.
I have slightly changed your code to do multiple runs (to accommodate for JS JIT warmup) and tried reproducing this in Chrome 77 and Safari 13.0.2.
  var it = 0;
  while (it++ < 5) {
    for (int i = 0; i < loops.length; i++) {
      final time = DateTime.now();
      loops[i]();
      print('Loop ${i + 1}: ${DateTime.now().difference(time).inMilliseconds}ms');
    }
    print("\n");
  }

In Chrome 77 I get
Loop 1: 427ms
Loop 2: 541ms
Loop 3: 543ms
Loop 4: 540ms

Loop 1: 407ms
Loop 2: 406ms
Loop 3: 541ms
Loop 4: 546ms

Loop 1: 270ms
Loop 2: 271ms
Loop 3: 271ms
Loop 4: 270ms

Loop 1: 262ms
Loop 2: 259ms
Loop 3: 258ms
Loop 4: 262ms

Loop 1: 259ms
Loop 2: 258ms
Loop 3: 255ms
Loop 4: 255ms

as you can see there is no real difference between for and while.
Now in Safari I got:
Loop 1: 525ms
Loop 2: 512ms
Loop 3: 516ms
Loop 4: 517ms

Loop 1: 257ms
Loop 2: 257ms
Loop 3: 512ms
Loop 4: 513ms

Loop 1: 257ms
Loop 2: 258ms
Loop 3: 513ms
Loop 4: 513ms

Loop 1: 256ms
Loop 2: 256ms
Loop 3: 516ms
Loop 4: 508ms

Loop 1: 253ms
Loop 2: 255ms
Loop 3: 508ms
Loop 4: 508ms

which indicates a difference. We can look at the generated machine code (you can use jsvu to get a JavaScriptCore binary - and then run it with --dumpDisassembly=true to get machine code dumped) to establish what exactly happens. Here is what JSC produced for the for-loop:
                  0x3782f8600390: inc %eax
                  0x3782f8600392: cmp %eax, %ecx
                  0x3782f8600394: jg 0x3782f8600390

and here is what it produced for the while loop
                  0x28377740058e: mov %ecx, %eax
                  0x283777400590: inc %eax
                  0x283777400592: jo 0x28377740065c
                  0x283777400598: cmp %edx, %ecx
                  0x28377740059a: jge 0x2837774005a7
                  0x2837774005a0: mov %eax, %ecx
                  0x2837774005a2: jmp 0x28377740058e

Note few differences: there is an overflow check at 0x283777400592 and there is some register reshuffling (because of the temporary variable). Overflow check arises most likely because range analysis if confused and can't prove that i stays within int32 range.
If you rewrite the code into while (++i < n) then these artefacts disappear.
Hopefully this answers your question.

@mraleph Thanks for the in-depth analysis. In the future I will attempt to do rigorous performance testing using a self-contained sample for reproduction when filing an issue. I see that performance issues are more complex.


Refactor Memo to follow the specification

Memo should be
memo = [ + (tstr / (bstr .cbor any)) ]

See specification in 1

Note: I have a PR in flight for this.

Tracking this in https://github.com/liftedinit/roadmap/issues/7


feat(#196): Add Unit Test For XmlNode

Add unit test for XmlNode. Also I refactored XmlClass a bit.
Closes: #196.

History:

feat(#196): remove unused methods
feat(#196): add more test methods
feat(#196): try to use XmlNode in XmlClass
feat(#196): fix all qulice suggestions
feat(#196): fix all jtcop suggestions

PR-Codex overview
This PR focuses on adding constructors to several classes and making some changes to the XmlNode class.
Detailed summary

Added constructors to XmlMethod, XmlField, and XmlMethod classes.
Removed the replaceArguementsValues method from XmlLabel and XmlBytecodeEntry classes.
Added equals, hashCode, and toString methods to XmlNode class.
Added tests for XmlNode class.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 4min)


Add "deploy" to settings.json schema

🌷

Implemented and now available since version 3.3.1.

Should make working with the settings.json file much easier :D


wip: hir refactoring

TBD

Thanks for reviewing things, and for the kind comments! As mentioned, things are quite close to finished now, the last thing that needs some fiddling is finding a Rust-friendly design for handling the interaction between patterns, builders/rewriters, and the rewrite driver (i.e. so that the rewrite driver is made aware of changes to the IR made by a rewrite pattern via the builder/rewriter).
Once that's out of the way, there is a short list of tasks to switch over to this new IR:

Port dominator tree and loop tree analyses on top of the new IR
Port data flow analysis framework on top of the new IR
Port liveness analysis and spills transformation using the data flow analysis framework
Wire up lowering from the new IR to MASM
Wire up lowering from Wasm to the new IR


chore: generalize retry configuration between both Datadog destinations

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#380  👈 (View in Graphite)
#379
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


fix: mock superchain version

Closing because it was fixed in https://github.com/defi-wonderland/optimism/pull/79


How to apply yup validation in "react-select" multiselect dropdown

I want to apply yup validation on a multiselect  dropdown which is created using "react-select" library. The form is created using formik.

{i18n.t('static.role.businessfunction')}*
 { handleChange(e); this.businessFunctionChange(e) }}
                                                            onBlur={handleBlur}
                                                            name="businessFunctions"
                                                            id="businessFunctions"
                                                            multi
                                                            required
                                                            min={1}
                                                            options={this.state.businessFunctionList}
                                                            value={this.state.businessFunctionId}
                                                            error={errors.businessFunctions}
                                                            touched={touched.businessFunctions}
                                                        />
                                                        {errors.businessFunctions}

{i18n.t('static.role.businessfunction')}*
 { handleChange(e); this.businessFunctionChange(e) }}
                                                            onBlur={handleBlur}
                                                            name="businessFunctions"
                                                            id="businessFunctions"
                                                            multi
                                                            required
                                                            min={1}
                                                            options={this.state.businessFunctionList}
                                                            value={this.state.businessFunctionId}
                                                            error={errors.businessFunctions}
                                                            touched={touched.businessFunctions}
                                                        />
                                                        {errors.businessFunctions}

This question is, unfortunately, unrelated to Workbox. I'm sorry that we can't be of help.

Sorry by mistake I added this question here.


Incompatible shapes: [100,10] vs. [100]

Logistic Regression
Incompatible shapes: [100,10] vs. [100]

Fixed in v0.5.


Add ALPN Buffering to support HTTP/2 Prior Knowledge

Motivation:
Currently, Netty cannot handle HTTP/2 Preface messages if the client used the Prior knowledge technique. In Prior knowledge, the client sends an HTTP/2 preface message immediately after finishing TLS Handshake. But in Netty, when TLS Handshake is finished, ALPNHandler is triggered to configure the pipeline. And between these 2 operations, if an HTTP/2 preface message arrives, it gets dropped. Here is some log:
21 Jun 2021 07:11:30.257 [epollEventLoopGroup-25-1] DEBUG i.n.c.DefaultChannelPipeline - Discarded inbound message PooledUnsafeDirectByteBuf(ridx: 0, widx: 121, cap: 249) that reached at the tail of the pipeline. Please check your pipeline configuration.
21 Jun 2021 07:11:30.257 [epollEventLoopGroup-25-1] DEBUG i.n.c.DefaultChannelPipeline - Discarded message pipeline : [ConnectionTracker#0, ConnectionTimeoutHandler#0, TLSHandler, ALPNHandler#0, DefaultChannelPipeline$TailContext#0]. Channel : [id: 0xad9d65dd, L:/<IP_ADDRESS>:9110 - R:/<IP_ADDRESS>:47036].

Modification:
Added buffering in ALPN Handler.
Result:
Fixes #11403.

/cc @normanmaurer
Not sure how good is the new API is but it's working fine on my tests,

The fix looks a little bit more complex than I expected. If it's because ApplicationProtocolNegotiationHandler calls configurePipeline() after passing through the connection preface, how about modifying ApplicationProtocolNegotiationHandler to buffer the received messages until it calls configurePipeline()?
On the other hand, we've been using something like this for many years and didn't see this problem, although YMMV.

@trustin Yeah, we can do buffering in ApplicationProtocolNegotiationHandler but it might not work with custom protocols. That's why I created the PipelineCallback class. It can support custom protocol on ALPN.
And yeah, by saying custom protocol, I really mean custom ALPN at TLS level. Maybe someone does it. :p
Any idea how we can make Http2PriorKnowledgeHandler a bit less complex?

And yeah, by saying custom protocol, I really mean custom ALPN at TLS level. Maybe someone does it. :p

I think we can consider that once we have a real use case :smile:

True, yeah. XD

@trustin PTAL.

@hyperxpro please ping when this is ready again

@normanmaurer PTAL

@normanmaurer
Tried to add a unit test but when I use SslHandler with EmbeddedChannel, it completes the handshake, and ALPN is also done in those few microseconds. Sort of race condition between Handshake completion and pushing backlog ByteBuf.
What should I do to test it properly? Need some ideas.

@hyperxpro let me have a look and see if I come up with something .

@hyperxpro I have some ideas... Can you please rebase ?

@normanmaurer Done! :)

@hyperxpro hmm... this doesn't look like its rebased to latest origin/4.1 . Can you double check ?

@hyperxpro hmm... this doesn't look like its rebased to latest origin/4.1 . Can you double check ?

Yeah, my bad. Fixed, PTAL

@hyperxpro PTAL... Added a testcase + adjust the code a bit to always forward on removal + also correctly call fireChannelReadComplete()

Looks good. Lemme test it against my CI.

@normanmaurer Works like a charm! Thanks a lot for helping. :)

Sending data to a server before ALPN negotiation has completed is questionable. Also, the spec specifically says prior knowledge should only be used on clear-text transports.
Is there something I don't understand about when messages can end up buffered?

@chrisvest thats a good point... that said I think we could still end up in "strange situations where because of sequencing we might only "half modified" the pipeline and one handler that was just added / removed did fire something through the pipeline. So I guess it might still be a good idea to buffer till we are sure we are done with setup the pipeline. WDYT ?


Fix some spelling mistakes

What type of PR is this?
/kind cleanup
/kind documentation
What this PR does / why we need it:
Just fixes a bunch of spelling mistakes found in the documentation.
Does this PR introduce a user-facing change?:

NONE

Thanks!
/lgtm
/approve


Default Native Library Name

The library name use with the DllImportAttribute to import the functions at run-time currently uses the Windows default naming convention of glfw3, as opposed to its Unix-like counterpart: glfw.
This causes anyone using the library on Linux/Mac to have to manually edit the library name and recompile, since they have no control over the name of native GLFW library as it gets installed on the system.
Since Windows users need only include the pre-built and portable binaries with their application, refactoring the native library name to glfw is trivial, and will not require editing the code or rebuilding, only the library name which they must provide themselves anyway.
Proposal is to change the constant to the Glfw.LIBRARY constant from glfw3 to glfw, so Unix users need only include the library and run it, and Windows users only need to apply a rename to the binaries while adding them to their project.
This should hopefully reduce hassle for everyone on all platforms, and enforce a standardized name "that just works" without all the extra mumbo-jumbo of resolving dependencies at runtime. Windows users will still need to account for CPU architecture and which binary to target, but that is unavoidable.

Cant we add and dll.config like https://github.com/opentk/opentk/blob/master/src/OpenTK/OpenTK.dll.config?
We can configure the new .csproj files to automatically copy this file the output directory.

AFAIK, the DLL map is framework dependent, and the way that Mono handles resolving native libraries. .NET Core uses AssemblyLoadContext, as well as there are cross-framework implementations like NativeLibraryLoader. For some reason another, .NET Core rejected the idea of implementing (see here and links within issue). Supposedly .NET Core 3.0 will be making some major improvements to this issue.
Changing the library name in this library will have no real effect, as the above mentioned methods will still need to be implemented if your application targets multiple frameworks and platforms. By changing the default name to drop the version suffix, it will allow Unix platforms to need no extra resolving. A Windows user will likely need to resolve the path regardless, as their are multiple binaries for x86 and x64.
By changing the name, it is basically a win-win. Nothing really changes on Windows platforms, worse-case scenario they need to edit the library name, and it will allow it to be found automatically on Unix platforms without need for resolving.
As stated above, the actual technique for resolving the library is going to be dependent on the application that uses it, and goes beyond the scope of any .NET Standard library. .NET Framework, .NET Core, and Mono all handle this differently. The name change will simply limit the number of scenarios where automatic resolving fails it need to go to a fallback in user-code, whatever way that will be.

Closing this for now.
Will likely revisit the idea with the official release of .NET Core 3.0, and the new features that will be including for native library resolving (the preview has issues on my Linux machine for proper testing).

@ForeverZer0 open this again for .Net Core now that 3.1 is out?

@Rjvs
Good call, will do. Work on this has been agonizingly slow, just life happening, but will be done in the foreseeable future.


Remove /doc prefix from multiple docs links

Description
Remove the /doc prefix from multiple documentations links.
I think this is what causes several links in the documentation to be broken.
Fixes #9684
Type of Change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] I stared at the code and made sure it makes sense

Suggested Checklist:

[ ] I have performed a self-review of my own code
[ ] My changes generate no new warnings

Hello, I am open to any feedback. Thanks.

thanks!


Multitouch (two or more 'fingers') during pan creates flickering effect

Bug report
Expected behaviour
When multitouch is performed, the expected behaviour is that only the first 'finger' is used for panning. All other touches are ignored. The panning is smooth and creates not flickering effect (switching very quickly between two or more pannings).
Actual behaviour
When multitouch is performed, the actual behaviour is that all touches are processed and a panning for each touch is performed very quickly behind each other. This creates a flickering effect (switching very quickly between two or more pannings).
Steps to reproduce the behaviour

Open any demo where panning is allowed on a device that supports touch events
Pan an svg-element with two fingers

Configuration

svg-pan-zoom version: The latest version from github
Browser(s): all
Operating system(s): all

Feature Request

Add an option to disable multitouch
Default behaviour should not be affected. So standard multitouch is enabled but an option to disable it would be super.
No, as the default behaviour is not affected

Hi @KoenkookpotPlasmans,
Sorry for a late reply.
I saw your PR and it looks good. And I agree that we should not introduce breaking changes, thus using an option to enable/disable desired behaviour is good. But in this case it seems that current behaviour is a bug, and fixing it will add benefit to all existing users, so we don't even have to use the flag. We just have to fix the behaviour.
There are some demos in the codebase on how to handle touch gestures. But they are based on simply disabling library's default behaviour and implement custom behaviour. So if anyone implemented custom behaviour using that method, they should not be affected by that change.
So hence the question - do you know of any use case where we would want the current behaviour? And if not then I'd propose to simply fix this behaviour. What do you think?

Hi @bumbu ,
I wasn't sure it would be considered a bug though the effect of using multiple gestures is quite 'annoying'.
I can't think of any use case where you would want this behaviour. I added the flag for enabling/disabling because I might have overlooked a use case for multiple gestures. But as we're both unable to find one, it might be better to simply not allow multiple gestures when panning.
I will change the PR so that the flag is deleted and the bug is removed if that's ok with you.

Ok, I changed the PR to have multitouch disabled at all times when panning.

Hi @KoenkookpotPlasmans,
Thank you for your update. The PR looks good. I'm currently on holidays, but as soon as I'm back I'll take action on it.

I was thinking about this issue and I'm not sure that isMultiTouchEvent is the right solution. Mainly because it assumes that first changed touch is not the first registered touch but from what I understand - often, first registered touch may be also the first changed touch. Although it should work correctly because the library uses only first changedTouch event, it adds distributed complexity.
It seems that a much easier approach would be to simply always use first event (evt.touches[0]) and not first changed touch. That should solve the problem with jiggering, is very easy to understand and is exactly what you described in expected behaviour.
Also I don't see the need for an option as this is a bug and not a feature.
What do you think @KoenkookpotPlasmans ?

Hi @bumbu ,
You are correct that using the evt.touches[0] instead of the changedTouch[0] also solves the issue.
However, multi-touch will trigger multiple events for each 'touch' that changed. So moving with for instance three fingers will trigger 3 events (from what I've seen in tests). with each time a different changedTouch. If we use evt.touches[0], the underlying code will still be executed 3 times, each time with the same touch/position.
The isMultiTouchEvent function will filter out any unnecessary events. So instead of three events triggering code, it will only allow the first touch to trigger further code. Less execution time seems better versus complexity (though in my opinion not that complex).
I thought I removed the option to enable/disable the event filtering from the pull request. No?

Oh, you're right - the option got removed. I thought it's still present.
You're right that if we're going to use evt.touches[0] then when there are other touches changing their positions - the underlying code will execute in vain. But it's execution will stop inside of this.viewport.setCTM(viewportCTM) as that method checks if new viewport is any different from previous viewport. So the execution will stop not far away from where the if (!Utils.isMultiTouchEvent(evt)){ is currently.
Also I agree that the code in itself is not complex, but half of the logic is in isMultiTouchEvent (ignore events where there is no first touch in changedTouch) and second half is in mouseAndTouchNormalize (use only first changedTouch touch data) - and that makes it complex overall.
So I'd go with the easier solution - always using evt.touches[0]. @KoenkookpotPlasmans what do you say?

Ah, yes. You check for any changes.
Then your solution is indeed the best. I'll change the PR for this and let you know but I'll do it as soon as possible.

Hi @bumbu,
I changed the PR to use evt.touches[0] and tested it on some devices and different browsers.
Can you let me know if this solution is the one we discussed?
Cheers,
Koen.

Hi @KoenkookpotPlasmans,
Yes, the code looks good. I'm going to test it, remove dist files and merge your PR. Hopefully that will be today!

Hi @KoenkookpotPlasmans,
You're changes are now in master. You can see that I closed that PR as I had so separate source code changes and build into separate commits.
I also published a new version on npm.
Thank you for all your time and effort!

Hi @bumbu ,
First of all thanks for making this awesome library and second thanks for helping me fix the bug!
I really appreciate it. Keep up the good work!
Cheers,
Koen.