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

This lib crashes on mobile Safari or Chrome in iOS #142

Closed
Madsim opened this issue Jul 15, 2021 · 2 comments · Fixed by #148
Closed

This lib crashes on mobile Safari or Chrome in iOS #142

Madsim opened this issue Jul 15, 2021 · 2 comments · Fixed by #148

Comments

@Madsim
Copy link

Madsim commented Jul 15, 2021

I don't have the possibility to get an error message, but found this lib to crash our app on mobile.
It's enough to import it, to cause the problem.

Reported it here as well: sindresorhus/get-urls#74

Update:

The Problem is caused by this line in v.5.3.1 (used by get-urls):
urlObj.pathname = urlObj.pathname.replace(/(?<!\b(?:[a-z][a-z\d+\-.]{1,50}:))\/{2,}/g, '/');

I don't know why get-urls is using such an old version, but maybe updating the dep will fix it.

@edenhermelin
Copy link

@sindresorhus we are also facing this issue on Safari (desktop), since they don't support negative lookbehind (?<=).
is there a chance to fix this? currently it requires us to freeze the dependency to an older version in our project

loynoir added a commit to loynoir/normalize-url that referenced this issue Aug 9, 2021
1. [test] Move `ava` to `mocha+chai` to test in real browser.
(sindresorhus#105) (sindresorhus#140) (sindresorhus#142)
2. [test] seprate non special-protocol-schemes(sindresorhus#147)
3. [doc] Update readme
@freben
Copy link
Contributor

freben commented Aug 11, 2021

@sindresorhus Another ping from us with Backstage as well. We (transitively) use this library in a browser env and just want to check with you, is it an intentional choice to keep the lookahead/lookbehind in place and abandoning Safari support? Or is it more a matter of not having had time to address it. I do see that the README of this package states that one should stay on the 4.x line if one needs browser support, but would you be willing to accept a change to the implementation to backtrack on that particular problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants