-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Change the minimum "supported" version of the Safari-browser to Safari 10 #12737
Conversation
I fully agree with this, and anything higher than Safari 9 (which is way too old in my opinion as well) seems reasonable to me. Let's indeed stick with |
…i 10 According to https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support, Safari 9 is still listed as "mostly supported". Given that the *last* release from the Safari 9 branch was on [September 1, 2016](https://en.wikipedia.org/wiki/Safari_version_history#Safari_9), it's questionable at least to me if it actually makes sense for us to even pretend to "support" such an old browser. Especially when the *first* release from the Safari 10 branch was on [September 20, 2016](https://en.wikipedia.org/wiki/Safari_version_history#Safari_10), which is now over four years ago. Based on the MDN compatibility data, this patch thus removes the following polyfills: - `TypedArray.prototype.slice()`, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/slice#Browser_compatibility - `String.prototype.codePointAt()`, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/codePointAt#Browser_compatibility - `String.fromCodePoint()`, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/fromCodePoint#Browser_compatibility
c3a97df
to
499d865
Compare
Something else, which I just spotted the other day, is that the update to Webpack 5 changed some default values. Note how there's now an Arrow function being used as part of the Webpack-header even in our Line 33 in 917fbf0
This can obviously be fixed by tweaking some configuration options, however looking at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility I'm not convinced that we need to do that if we accept this patch since all browsers that we support should then have native Arrow function support. |
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/983a5d04b6bd381/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/983a5d04b6bd381/output.txt Total script time: 4.17 mins Published |
Looks good to me. I'll update the FAQ page. |
Thanks for doing this! Looking more closely on that list, I do wonder if we actually need to keep the "Safari 9 and below"-line since it honestly seems redundant now; I'd suggest just removing it. |
I agree; it's removed now. |
According to https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-support, Safari 9 is still listed as "mostly supported".
Given that the last release from the Safari 9 branch was on September 1, 2016, it's questionable at least to me if it actually makes sense for us to even pretend to "support" such an old browser.
Especially when the first release from the Safari 10 branch was on September 20, 2016, which is now over four years ago.
Based on the MDN compatibility data, this patch thus removes the following polyfills:
TypedArray.prototype.slice()
, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/slice#Browser_compatibilityString.prototype.codePointAt()
, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/codePointAt#Browser_compatibilityString.fromCodePoint()
, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/fromCodePoint#Browser_compatibility