Update supported browser versions #1006
Conversation
ajwild
commented
Jun 12, 2025
- I've updated the versions to 1 year before the next release month, so in this case they are the most recent versions from June 2024 ready for the July 2025 release. If there's ever a difference between the Chrome and Edge version then I would make Edge match the Chrome version even if it ends up being 51 weeks old. Edge seems to have the an aggressive update policy so I doubt this will be an issue.
- I've dropped iOS Safari because it's always the same version as regular Safari, and we don't list Chrome for Android separately (even though Can I use... lists these separately).
- I've dropped Opera because we only had 10 of 4000 users on TrackJS using it, it's based on Chrome (or at least the same engines), it's generally up-to-date versions that we see, and I don't think anyone is actively developing or testing with it.
| @@ -52,7 +52,7 @@ systemRequirements: | |||
| - name: Livingdocs Editor Docker Image | |||
| version: livingdocs/editor-base:20:10 | |||
| - name: Browser Support | |||
| version: Edge >= 92, Firefox >= 90, Chrome >= 92, Safari >= 15.4, iOS Safari >= 15.4, Opera >= 78 | |||
| version: Chrome >= 126, Edge >= 126, Firefox >= 127, Safari >= 17.5 | |||
There was a problem hiding this comment.
We didn't do any code update in the editor to enforce that 🤔
So I wouldn't change that in this release. Do you know of a feature we're using we should put into https://github.com/livingdocsIO/livingdocs-editor/blob/main/app/scripts/browser_is_supported.js ?
There was a problem hiding this comment.
I wasn't aware of that file. Do we really need to do this? If one user complains and we say we support Safari 15.4 then we need to fix it, but if we keep an up-to-date list then they need to update their browser. It's also a lot easier for us to check Can I Use... for 1 year of browser support.
The reason this came up is because I wanted to use Promise.withResolvers(). At this moment there's nothing specific in the code that I'm aware of, but I don't think anyone has been monitoring, and we also don't do any testing with these old browsers. There might also be a few unsupported CSS changes.
There was a problem hiding this comment.
Basically we could take this into the september release.
But I wonder whether we should first break older versions and then do this change with november.
In general, we definitely want to maintain that file to show the browser is not supported error screen.
diff --git a/app/scripts/browser_is_supported.js b/app/scripts/browser_is_supported.js
index 48465ed21..2c7f2abc0 100644
--- a/app/scripts/browser_is_supported.js
+++ b/app/scripts/browser_is_supported.js
@@ -48,7 +48,7 @@ const featureDetections = [
// we need dynamic imports for dynamic dependency loading (webpack chunks)
function dynamicImports() {
// eslint-disable-next-line
- new Function('import("")')
+ new Function('import("").catch(() => {})')
},
// Edge >= 15
@@ -64,14 +64,23 @@ const featureDetections = [
new Function('async () => {}')()
},
+ // Chrome >= 39
// Edge >= 13
// Firefox >= 26
- // Chrome >= 39
// Safari >= 10
// iOS Safari >= 10
function generators() {
// eslint-disable-next-line
new Function('(function* () {})')()
+ },
+
+ // Chrome >= 119 (November 2024)
+ // Edge >= 119 (November 2024)
+ // Firefox >= 121 (December 2024)
+ // Safari >= 17.4 (March 2024)
+ // iOS Safari >= 17.4 (March 2024)
+ function promiseWithResolvers() {
+ return typeof Promise.withResolvers === 'function'
}
]