<Link>s can stop working when opening app in a new tab at a route other than /

[amoeba]

Bug report

Describe the bug

Clicking on certain <a> elements produced by <Link> elements doesn't work after I follow the steps below which includes opening the app in two new tabs. I also found a way to get it to fix itself. I found this because I have a real app that I'm having similar behavior in so I tried to reproduce it with a Next.js example app.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

First grab a copy of my repo, set it up, and start the custom server:

(It's based on https://github.com/zeit/next.js/tree/master/examples/custom-server)

git clone git@github.com:amoeba/nextjs-links-break.git
cd nextjs-links-break
npm install
npm run dev

Then:

1. Open localhost:3000 in browser
2. Click link to a
3. Open a new blank tab (e.g., Cmd+T)
4. Go to localhost:3000/a
5. Click link to b
6. Open a new blank tab (e.g., Cmd+T)
7. Go to localhost:3000/b
8. (Try) to click link to a, see it doesn't work

I seem to be able to fix this if, at this point, I click the link to b. Then, other links work.

Expected behavior

I expect the clicks to always result in a page change.

Screenshots

System information

• OS: Mac OS Mojave 10.14.3
• Browser (if applies): Tested in recent Chrome and Firefox Nightly
• Version of Next.js: 8.0.3

Other info

I'm not really sure if this is related to other issues, such as #5478.

[ijjk]

@amoeba Thanks for the helpful reproduction! After further investigation, it looks like this is due to maxing out the browser's restriction on max-number of connections per hostname. Each page creates 2 persistent connections to the server to get hot updates and keep pages active.

In Chrome and Firefox, it appears this limit is 6 persistent connections per hostname or server. In Firefox you can increase the limit by going to about:config and setting network.http.max-persistent-connections-per-server to a higher number.

See here for a little more info on the limits in each browser.

[amoeba]

Thanks for looking into this @ijjk! Your answer makes sense. My interpretation of this is that this isn't necessarily a bug and this Issue could be closed.

That said, I produced this example to help debug a slightly different issue I'm seeing on a real project. I don't want to hijack this Issue since maybe the issue in my real app is different, but I was able to reproduce and fix this behavior.

Steps:

git clone https://github.com/amoeba/nextjs-broken-links
cd nextjs-broken-links
npm install

Then:

• Open http://localhost:3000/object/test in a web browser
• Notice the links Index and Test don't work. Also notice the styles aren't rendering as expected.

What I found out tonight caused this was that https://github.com/amoeba/nextjs-broken-links/blob/master/pages/object.js didn't have import my CSS as index.js does and adding the proper import to object.js fixes the broken links. Do you think this is a next.js issue or perhaps a next-sass issue?

[Yzrsah]

This issue can cause inexplicable behavior for visitors to a site/app who open tabs but do not understand persistent connection counts.

This is an important issue because no broken behavior should be exposed to the outside world without some explicit error handling. A page should never be rendered in an invalid state.

[ijjk]

@Yzrsah this isn't an issue for visitors since the persistent connections that Next.js makes are only done in development mode. Also, there are no errors occurring on the page the problem is that the request for the page is stalled by the browser until a connection frees up. I think it would be nice if the browser showed a warning or something saying the site is out of persistent connections and to close a tab to free them up.

@amoeba Yeah that other issue appears to be with next-sass and possibly next-css. I'm going to close this one. If you could open an issue at the next-plugins repo with your reproduction, it can be looked into more.

[timneutkens]

We can add a message to the console to make it clear that the connection could not be established.

[amoeba]

Thanks @ijjk I'll do that. @timneutkens that'd be a good user experience I think. 👍

[Janpot]

I guess this issue started after moving to window.EventSource. Polling doesn't have this problem because it doesn't keep connections open. Neither do websockets because AFAIK they are not subjected to these limits.

Maybe one of the following solutions could be explored as well?

• Revert back to polling or websocket (I guess these are out of the question, especially the websocket)
• Try to find a way to multiplex multiple tabs over a single window.EventSource. I wonder if a SharedWorker can accomplish this.

[Yzrsah]

@ijjk

@Yzrsah this isn't an issue for visitors since the persistent connections that Next.js makes are only done in development mode.

Could something else be causing it? I seem to be having the issue on my live site when opening multiple tabs

I'm also seeing the issue on other people's sites:
https://next.material-ui.com/

This site begins failing when opening tabs

[ijjk]

@Yzrsah I just tested going to https://next.material-ui.com/ and opening 6 tabs and navigating throughout each tab and it works fine. Could you provide a reproduction?

I also just tested it on https://nextjs.org by opening 8 tabs and navigating throughout and wasn't able to reproduce.

[Yzrsah]

It only happens when I have too many tabs open. After killing all tabs, the sites start working again. More than 6, like 30+ tabs on each site. I'll have to track down the issue further

[timneutkens]

@chuyik try using next@canary

[KeitelDOG]

2020 with next 9, I'm having similar issue too, with Link that randomly stops working, with no console notification on that. I'm happy that's it's only in DEV mode, but also it can be annoying when presenting some Dev works to your team and suddenly your link does not work, and yourself didn't know why at that time, making you look a bit unprofessional. So a notification on this would be very helpful for new NextJS developers.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.