Safari 10 Support

[Timer]

Do we want to support Safari 10? This browser is end-of-life but seems to still have a decent number of active users.

We've had at least two issues crop up about it (I've seen more that I don't have on hand):
Fixes #9782
Fixes #9827

This is due to Safari 10 incorrectly implementing URL, so Next.js wont work even if users polyfill support back. As a result, client-side transitions try to happen via server-side and fail:

Correct behavior (Safari 11+):

[lachlanjc]

I ran into this the other day. I was trying to present a site I made on a school computer & all the links didn’t work at all—they didn’t even degrade as I expected to regular a tag behavior, they just didn’t work. Good to know why that was happening.

[ghost]

#9782 protocol can use RegExp, so the problem will be resolved.

[ahmadawais]

I just wanted to chime in here and share that I am having the same issue on iPhone 7/8 for a Next.js/Zeit based game we intend to launch mid-January (by which I mean we are excited; it's not meant to put pressure here during the vacations at all). The app just gets stuck and there isn't much there in the console to file an issue. It's most definitely an issue with routing though.

I also have an update that on iPhone 7 with the latest Chrome and Safari versions, this issue exists whenever users click a next.js Link component. I'm investigating what I can do there since it works everywhere else except for the old iPhone (even with new software).

P.S. Please work on this after the vacations. It's not a blocker for anything.

[ghost]

In our company's business project, We use next.js with version 9.16, some users report us to could not visit our web app, it makes me so depressed and it is a thorny issue. I try to fix it in my private NPM, I find building the next.js project so difficult.

[tpreusse]

We had to roll back from 9.1.6 to 9.1.4 after discovering that all links broke on iOS 10 (reported by users). Clarification: Links broke starting with 9.1.5.

In dev I then got «Invalid href passed to router» in the simulator. Downgrading to 9.1.4 solved it:
orbiting/republik-frontend@3aa7513

For us the links completely broke. Not falling back to server-side navigation. It might be a good idea to ensure that native a tag navigation still happens in production when Router throws an error. But would make it harder to detect it in dev 🤷‍♂

Move preventDefault after Router call?
https://github.com/zeit/next.js/blob/1546fcdcfd871cde1ffc0fce4ba9153c2786d0e2/packages/next/client/link.tsx#L189-L206

We also use next-routes, maybe the combination had an impact but I don't think so.

[olpeh]

This is definitely a blocker for us and we are currently waiting for this to be implemented before upgrading. Hope you could prioritize this.

[carloscuesta]

We're using 9.2.0 and found the exact same problem. Can confirm that downgrading to 9.1.4 fixed the problem as @tpreusse points out 🙏

[timneutkens]

This issue is solved in 9.2.1

[carloscuesta]

Wow! That was fast. Really appreciate the work you put on this project. Thanks!

The issue should be closed then @timneutkens

[timneutkens]

We kept it open as there's a few other issues related to native-url.

[karl]

It looks like this bug is back in 9.2.2-canary.15.

I've tested 9.1.7 and it displays the bug as expected, it is fixed in 9.2.1, but has re-appeared in 9.2.2-canary.12 (and is still present in 9.2.2-canary.15).

The bug is still fixed in 9.2.2-canary.11. I wonder if this change (#10419) in 9.2.2-canary.12 is the cause of the bug re-appearing?

[timneutkens]

@carloscuesta based on @alexypdu this issue has been fixed 👍

[borisdedejski]

It is not working again I have next 9.4.4 and it is not working in safari :(

[timneutkens]

It is not working again I have next 9.4.4 and it is not working in safari :(

Try next@canary, we recently made some more updates for edge cases with Safari

[joaobibiano]

Guys, I'm using next v10, and my website does not load on Safari.

Something that can I do?

[joaobibiano]

We also got reports about broken links again from users with old iOS and Android versions.

The problem seems to be that native-url returns a protocol on those devices even when it shouldn't. Probably a problem that only occurs in combination with the url-polyfill and maybe even then with certain browser engine version only.

@olpeh I used a ultima ratio solution for now and disabled native-url via next.config.js:

module.exports = {
  webpack: config => {
    const alias = { ...config.resolve.alias }
    delete alias.url // alias to native-url
    config.resolve = {
      ...config.resolve,
      alias
    }
    return config
  }
}

(by doing that you'll also loose the 7kb optimisation of native-url on all platforms)

Specifically broken were: iOS 9.3 (reproduced in Simulator), Android 6 (only reported, not reproduced)

@Timer would you like to see the root issue solved in native-url/url-polyfill or could you also imagine adapting the protocol check in the router?
https://github.com/zeit/next.js/blob/b274fe39d38111588e625342a89dc568ad38fff5/packages/next/next-server/lib/router/router.ts#L395-L404

(e.g. doing a string check on the unparsed url like url.match(/^[a-z]+:/))

The «not returning a protocol» logic of native-url is quite convoluted 🙈
https://github.com/GoogleChromeLabs/native-url/blob/19aacc0a82f7e36995bde6adc6876f6140d6d06a/src/parse.js#L95-L126
So wouldn't be surprised if more accidental protocol returns happen down the line.

Using this I'm be able to render the website! But I lost the translations.... Can you help me?

[joaobibiano]

We also got reports about broken links again from users with old iOS and Android versions.

The problem seems to be that native-url returns a protocol on those devices even when it shouldn't. Probably a problem that only occurs in combination with the url-polyfill and maybe even then with certain browser engine version only.

@olpeh I used a ultima ratio solution for now and disabled native-url via next.config.js:

module.exports = {
  webpack: config => {
    const alias = { ...config.resolve.alias }
    delete alias.url // alias to native-url
    config.resolve = {
      ...config.resolve,
      alias
    }
    return config
  }
}

(by doing that you'll also loose the 7kb optimisation of native-url on all platforms)

Specifically broken were: iOS 9.3 (reproduced in Simulator), Android 6 (only reported, not reproduced)

@Timer would you like to see the root issue solved in native-url/url-polyfill or could you also imagine adapting the protocol check in the router?
https://github.com/zeit/next.js/blob/b274fe39d38111588e625342a89dc568ad38fff5/packages/next/next-server/lib/router/router.ts#L395-L404

(e.g. doing a string check on the unparsed url like url.match(/^[a-z]+:/))

The «not returning a protocol» logic of native-url is quite convoluted see_no_evil
https://github.com/GoogleChromeLabs/native-url/blob/19aacc0a82f7e36995bde6adc6876f6140d6d06a/src/parse.js#L95-L126
So wouldn't be surprised if more accidental protocol returns happen down the line.

@tpreusse Do you have other alternative than that ? Because my translations "next v10" stopped working

[joaobibiano]

Hello i just wanted to say it doesn't work on iphone. Everytime i go on my website its just a blank page and it dosent matter what browser i am using. I tried all browsers, still white page. You can test it on the site animex.ninja

Please check aralroca/next-translate#508 (comment)

[SSylvain1989]

Hello. Same issue here..
Anyone solve it ?
It's really very annoying to put together a whole project and see that it doesn't work !
Put this issue in the front page on nextJs... Waste of my time.

Édit : solution here https://stackoverflow.com/questions/63055442/react-next-js-site-doesnt-load-properly-in-safari-blank-page/66772524#66772524
I have remove my custom Google fonts and let nextjs font by default
Works fine on safari and iPhone

[machineghost]

Just one more vote to re-open. I don't have any special fonts on my site, but I have users reporting it doesn't work, only on Safari (but it works fine one every other browser).

[SSylvain1989]

Il you use any other font it will brake that was the case for me

[bayraak]

Issue continues

[renvieir]

Having the same issue

[lachlanjc]

Also had user reports of my site being unavailable on Safari 10.

@timneutkens This issue was re-introduced with Next 10—there's internals of Next using un-polyfilled methods Safari 10 doesn't have available

[machineghost]

Guys, the Next.js devs just don't believe you: they believe there is nothing wrong with the library, and it's our fault. See #24202 (comment) ... I tried to get them to pay attention to this issue, and they literally said:

we have tests covering Safari 10.1 here https://github.com/vercel/next.js/runs/2374476653 which are passing correctly.

So until someone spoon-feeds things to them (eg. by providing a failing test case) it's simply going to go unaddressed, because they don't believe it's their fault.

[lachlanjc]

@machineghost The Next.js team is juggling literally thousands of issues/PRs/comments while trying to build & release new features—this issue didn't have a specific reproduction, so I don't blame them for not prioritizing it.

For me, the issue is with next/image's, specifically on layout="responsive". The client bundle is ending up using .matchAll, which would need a polyfill.

Source code causing the issue:

next.js/packages/next/client/image.tsx

Line 107 in c76170e

const viewportWidthRe = /(^|\s)(1?\d?\d)vw/g

I tested this on Safari 10.1 on macOS Sierra on BrowserStack. Happy to provide any more details if needed.

[timneutkens]

For me, the issue is with next/image's, specifically on layout="responsive". The client bundle is ending up using .matchAll, which would need a polyfill.

This has been fixed recently (currently on canary), also affected IE11.

Guys, the Next.js devs just don't believe you: they believe there is nothing wrong with the library, and it's our fault. See #24202 (comment) ... I tried to get them to pay attention to this issue, and they literally said:

What JJ said is that there are tests covering that version of Safari and that they're currently passing, meaning that the issue that you're running into is not easily reproducible (which we tried) and because you did not provide a reproduction the issue is not actionable and can't be investigated further, which is clearly mentioned in the issue template.

If you're running into a particular issue please first check if there's an open issue similar/same to yours, if there is no open issue for it please open a new issue that follows the full issue template which includes providing a reproduction so that it can be looked at / advice can be provided.

As @lachlanjc said we handle approximately 100 to 150 notifications every day and "same issue" on a closed issue that has tests is unfortunately not enough to be able to reproduce an issue in one particular app without knowing what customization, libraries, settings, etc. are used.

So until someone spoon-feeds things to them (eg. by providing a failing test case) it's simply going to go unaddressed, because they don't believe it's their fault.

This has nothing to do with "whose fault it is" or not acknowledging something in your app is not working as you intended, it's about being able to investigate and fix a bug that you're reporting, we tried to investigate but could not find an issue because you did not provide a reproduction.

You don't have to provide a test case, only a repository that can be investigated.
The reproduction also generally applies as a base for the integration tests we add.

Every bugfix/feature PR has tests added to the test suite, it's currently holding over 3400 integration tests which are expanded every day and run on every PR.

[machineghost]

To be clear, if you review my last comment I was in no way blaming anyone; I was simply describing (in blunt terms) the current state.

Look, on any OSS project, the team will take it upon themselves to fix some issues without reproduction steps, because the problem is obvious: it's clearly it's "the library's fault". Other tickets have nothing to do with the library, and result from user confusion, so the team will (legitimately) keep blaming outside sources, demanding reproduction steps or other proof (which will never come).

... and some issues seem to obviously be the library's fault to the user ... but don't seem to be to the maintainers. This is one of those issues. Such issues have to be "spoon fed" with reproduction steps and other details, because the user thinks it's the first type of bug, and the team thinks it's the second.

As such, if we (users) want them (the Next.js team) to fix this problem, we have to "spoon-feed" them proof that it originates in Next.js code (ie. it is Next.js's "fault"). My comment (and it's blunt tone) was absolutely meant to try and encourage such "spoon feeding" from the users here, or maybe draw some dev attention ... but again, I was in no way faulting anyone.

I personally don't believe user bug reports all the time, and I'm sure most devs in the thread have had similar experiences.

[lachlanjc]

Update: canary solved my issue! Thanks for your work there @timneutkens.

[timneutkens]

Just to be clear we tried to reproduce this issue in various ways but could not reproduce it. Here's 2 separate urls: one a basic page and one an enterprise-grade Next.js app with hundreds of pages / thousands of components, both on the latest version:

• https://my-app-testing-3lfhobyc5-timvercel.vercel.app/ (latest canary)
• https://vercel.com (10.2.0)

Both were tested in Browserstack on real devices:

• iPhone 7 with iOS 10, which uses Safari 10
• macOS Sierra which uses Safari 10.1

As you can see both run completely fine with Safari 10, so we can't investigate more than we already have without a reproduction.

but again, I was in no way faulting anyone.

You literally said this:

Guys, the Next.js devs just don't believe you

Which is not true, we asked for a reproduction as the issue that you're having in your particular app can't be reproduced on other applications. If you provide a reproduction we'd be happy to take a look and investigate.

Your choice of words is not very helpful, especially after we spent multiple hours investigating your issue without a reproduction provided.

[machineghost]

Why not open this issue then?

A closed ticket ultimately says "we don't believe this is an issue". An open ticket (with comments saying "we need reproduction steps to fix this") says "we believe this is an issue ... but we can't solve it without your help."

[timneutkens]

Why not open this issue then?

Because this issue was fixed in 2019 and tests for this case were added. As said we'd be happy to take a look at any issue that follows the issue template which requires a reproduction to be provided.

[amirhosseinkh2515]

have the same problem on next 11.1.2 please reopen and fix this please .

[timneutkens]

Please open a new issue with a reproduction.