Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari 10 Support #9851

Closed
Timer opened this issue Dec 27, 2019 · 49 comments · Fixed by #10526
Closed

Safari 10 Support #9851

Timer opened this issue Dec 27, 2019 · 49 comments · Fixed by #10526
Milestone

Comments

@Timer
Copy link
Member

Timer commented Dec 27, 2019

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:

image

Correct behavior (Safari 11+):
image

@Timer Timer added this to the 9.2.0 milestone Dec 27, 2019
@lachlanjc
Copy link
Contributor

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
Copy link

ghost commented Dec 30, 2019

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

@ahmadawais
Copy link
Contributor

ahmadawais commented Dec 31, 2019

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
Copy link

ghost commented Jan 3, 2020

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
Copy link
Contributor

tpreusse commented Jan 3, 2020

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
Copy link

olpeh commented Jan 17, 2020

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
Copy link

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
Copy link
Member

This issue is solved in 9.2.1

@carloscuesta
Copy link

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

The issue should be closed then @timneutkens

@timneutkens
Copy link
Member

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

@karl
Copy link

karl commented Feb 11, 2020

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?

@Timer Timer modified the milestones: 9.2.x, 9.2.2 Feb 13, 2020
@timneutkens
Copy link
Member

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

@Timer Timer modified the milestones: 9.x.x, iteration 3 Jun 15, 2020
@borisdedejski
Copy link

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

@timneutkens
Copy link
Member

timneutkens commented Jun 20, 2020

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
Copy link

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

Something that can I do?

@joaobibiano
Copy link

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
Copy link

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
Copy link

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
Copy link

SSylvain1989 commented Mar 23, 2021

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
Copy link

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
Copy link

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

@bayraak
Copy link

bayraak commented Apr 24, 2021

Issue continues

@renvieir
Copy link

Having the same issue

@lachlanjc
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

@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.

image
image

Source code causing the issue:

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
Copy link
Member

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
Copy link

machineghost commented May 13, 2021

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
Copy link
Contributor

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

@timneutkens
Copy link
Member

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:

Both were tested in Browserstack on real devices:

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

Screen Shot 2021-05-14 at 11 36 34

Screen Shot 2021-05-14 at 11 35 59

Screen Shot 2021-05-14 at 11 33 32

Screen Shot 2021-05-14 at 11 32 33

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
Copy link

machineghost commented May 14, 2021

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
Copy link
Member

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
Copy link

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

@timneutkens
Copy link
Member

Please open a new issue with a reproduction.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet