Given this, should we update our strategy to include Firefox ESR? I’m against it, but @MichaelHamann is for it. Pasting our discussion from #xwiki:
@MichaelHamann
I would prefer changing our support strategy to include the Firefox ESR version and to change the environments build to also test with the oldest supported ESR version as this seems to be the update strategy for the ESR version (they update to the new version when the x.3 release has been published, which is the same as when the previous ESR version becomes unsupported). To me, this would be consistent with how we support LTS versions of other software. In practice, this means that you can use features that have been out for at least 15 months, and in many cases that time interval is actually shorter.
Actually, I might be wrong regarding when ESR branches become unsupported, but I think it would be reasonable to switch to a new LTS branch on the .3 release
@mflorea
I prefer we don’t support Firefox ESR because:
adding a couple of more builds on CI (for each XWiki branch we support) would make it even slower than it is
automated tests are not covering everything so we’d have to ask @ilie.andriuta to add Firefox ESR to his manual test suite, which, AFAIK, already takes a lot of time (even when doing only smoke tests), for all the XWiki branches we support
not being able to use recent JavaScript APIs that are supported by stable versions of all major browsers is a big draw back for me
it adds complications and possibly technical dept:
you need to leave a comment (TODO) to simplify your code when we increase the supported ESR version
we need to be notified when the oldest supported ESR version is increased in order to update our build and possibly our code
do we handle ESR differently in XWiki LTS (e.g. 16.10.x) and latest stable (17.x)?
All this for what? Do we know how many users are using Firefox ESR? Based on Browser Market Share Worldwide | Statcounter Global Stats Firefox is 2.37%, so ESR must be way less. Sure, this stats may not reflect exactly XWiki usage, but still, I doubt ESR is used enough to be worth the cost it adds for us to support it.
@MichaelHamann
Regarding CI, my suggestion would have been that we change one of the two Firefox-based builds that we currently already have in the environment tests to use the ESR version. As it seems unlikely that old code behaves differently in the ESR version than the latest version and new code usually has good test coverage, I would have argued that it is enough to have automated tests and no manual tests.
I agree that it seems difficult to find compatibility data for the ESR version, which seems surprising given that MDN is managed by Mozilla.
So it looks like Michael is +1 while I’m -0. What’s your position on this?
… the only environments I know Firefox to be deployed in the ESR version are mid to large enterprises to ensure a more consistent and reliable update experience (also related to AddOn). If xWiki has a relevant user base in such environments, it might be relevant, if not, not worth the efforts, although the mid to large enterprises might be the ones paying for the services via xWIKI SAS.
While full support for Firefox ESR would be nice, I concur that is has a tiny user base and is likely not worth too much effort.
A potential compromise could be to limit this support to one/few XWiki release channels. There, support for the very latest release could help identify issue early and avoid extensive backporting.
Even if there is no official support for Firefox ESR, it would be nice have best effort support for it: addressing major issues (e.g. editor unusable, not minor visual stuff etc.), if and when they are found i.e. by users, especially if it an immediate fix would be on the simpler side.
First, I want to point out that browser usage is a complex topic and need careful consideration.
For the analysis below, I’m going to trust the numbers provided by https://browsersl.ist/
From our browsers support strategy we can see that we are only testing for 2.1% for the users worldwide (3.1% of Europe, 2.7% of France, 4% of Germany, 4.2% of North America).
Now we are covering 89.3% of browsers worldwide (which is still quite a lot).
In this case, we’d need to limit our API use to
chrome for android 138 (but it’s surprising to only see one version)
chrome 109 to 138
safari for iOS 11.0-11.2 to 18.5
edge 136 to 138
safari 15.6 to 18.5
samsung 27 to 28
firefox 11 to 140 (ESR is currently 128)
opera mobile 80
UC browser for Android 15.5
firefox for android 140
I think this makes a good case for supporting a wider set of browsers than we currently do.
So my short answer is, +1 to support firefox ESR (and more).
But I agree this is raising many questions:
should we agree on a query to feed browserlist to know which set of browsers to support. And when do we refresh this list?
how to know as a dev which API is available for all those browsers?
should we generalize the use of polyfil
how do we detect the use of too recent API statically or dynamically?
how do we test on more kinds of browsers:
without exploding the CI time
using new kinds of browsers we currently don’t support (e.g., smartphone browsers).
PS: browserlist allows for the use statics exported from analytics, so we could query on statistics from xwiki.org, at the risk of being biased as it’s possibly not representative of all cases where XWiki is deployed.
PS2: browser list also allow to query by browser release age. For instance:
since 2010 = 96.7 %
since 2020 = 95.3 %
since 2021 = 95.0 %
since 2022 = 94.8 %
since 2023 = 93.5 %
since 2024 = 88.6 %
since 2025 = 82.6 %
We can notice that the more recent we go, the smaller the audience get (with a sharp decrease around 3/4 years old).
This sadly matches hardware renewal, so it could be a sign that people are changing hardware because the software is not upgradable anymore, leading to broken website using unsupported APIs.
I’m neutral on the topic. Unfortunately I’m not sure Firefox ESR would fit very strictly to our current definition of supported browser. On paper it would be nice, but it might create complications for not that much benefit.
Thank you for the analysis mleduc!
Note that I would have done the same. On Promise.try() - JavaScript | MDN there’s a banner saying it’s a baseline 2025 feature so I’d have assumed this was okay to use. The way I estimate if I can use a feature so far is by compatibility with the XWiki supported browsers (and a bit of common sense ofc).
I believe our definition of supported is very strict and we could use a category of browsers with looser conditions. Putting latest Android Chrome at the same level of support as IE3 sounds weird to me. Here is a quick draft for a proposal, just to share the idea. The exact conditions need to be thought of carefully and could be discussed in another topic if there’s any interest in the idea:
Accepted browsers for XWiki are commonly used browsers. All supported browsers are accepted. Issues created for accepted browsers in JIRA are not closed as won’t fix and we make a best effort to fix them. Contrary to Supported browsers, no engagement is made on testing them and on the compatibility of new features. The complete and precise list of accepted browsers in a given release is indicated in the Release Notes for that release. At release date, the browsers in the list at Browserslist are defined as Accepted for this release. Browsers that are neither supported nor accepted will have their related issues closed as Won't Fix and fixes for them will not be merged to the codebase. Fixes specific for previously supported or accepted browsers can be removed.
Let me know what you think of this idea and if it’s worth starting a brainstorming/vote over it
Most XWiki users will upgrade several months (or even more than 1 year if they’re on LTS, in practice it’s probably several years, see “Top 10 XWiki versions” widget at https://www.xwiki.org/xwiki/bin/view/ActiveInstalls/Active%20Installs%20v2/ . So by the time they upgrade, the browser version market share tested with XWiki at the time will have increased.
Since we upgrade the version of the browsers we test with continuously, this means that we actually tests with a lot of browser versions! A lot more than just the latest, allowing us to catch problems. Ofc we don’t test everything on all versions but we probably have a good coverage.
I believe we’ve covered most of these these browsers
Note that our goal is not to be perfect but to provide a strategy that allows us to have a good quality at a reasonable cost. Right now, I don’t remember seeing a lot of issues reported that were caused by browser compatibility issues. We get some from time to time but they’re scarce.
So I’d say our current strategy is working fine and I wouldn’t change it. Changing it will have a cost and I don’t see anything justifying this extra cost ATM.
So I’m -0 to add a new browser to test on (i.e. FF ESR). I feel that our current strategy works well enough.
