First of all, thanks for Vaadin 25. The native Popover-based overlays are a real improvement, and I appreciate that PR vaadin/flow#26191 now aligns the old-browser check with the browsers the frontend is actually built for. Apps silently half-working in older browsers was worse than a clear message.
I’d like to discuss how browser support changes are communicated, based on our recent experience.
What happened
We upgraded our customer’s banking portal to Vaadin 25.2. Users of Firefox ESR 115 are now redirected to ?v-r=oldbrowser. ESR 115 still receives security updates from Mozilla (currently 115.42) and is scheduled to be maintained until at least March 2027. In Germany, Firefox has a large user base, and some companies still run ESR 115, which is maintained and accepted by public-authority and banking websites. Our customer’s support team received a number of frustrated calls and emails, because to these users the portal seemed to stop working overnight.
We would have planned and communicated the upgrade differently had we known. However, I couldn’t find any explicit notice:
The 25.0 release notes list “Firefox (evergreen), Firefox Extended Support Release (ESR)”. When 25.0 was released, ESR 115 was a maintained Mozilla ESR, so we read this as including it.
The upgrade guide from 24 to 25 does not mention browser support changes.
The switch to the Popover check (PR vaadin/flow#23078) is marked as a breaking change, but only in the PR itself.
The picture gets harder to explain
Vaadin 25.0–25.2 rejects ESR 115, which still gets security updates, but accepts ESR 128, which has had none since August 2025.
25.3.0 changed the build target to concrete versions (firefox140, safari17.6; PR vaadin/flow#25777). This effectively drops further browsers in a minor release. A patch release then adjusts the check to match (PR vaadin/flow#26193).
ESR 140 reaches end of life reaches end of life on 13 October 2026, but stays nominally supported.
So “outdated and insecure” is hard to use as an argument towards end users. And the compatibility page (“evergreen”, “ESR”) doesn’t tell us which concrete versions to expect, although concrete minimum versions now exist in vite.generated.ts.
So my questions are:
Could the concrete minimum browser versions be documented on the compatibility page and kept in sync with the build target?
Would you consider treating a raised browser baseline as a breaking change: announced in the release notes (github) and upgrade guide?
Can we expect browser baseline changes in minor or major releases, only? Never in a patch?
What does “Firefox ESR” mean going forward: only the latest ESR, or every ESR that Mozilla still maintains? An early notice when a maintained ESR will be dropped would give us time to prepare our customers and avoid dissatisfaction.
Thanks for taking the time to read this. I’d love to hear how others handle browser support in their projects, and of course your perspective. @knoobie , since you raised the original question in vaadin/flow#23026 and reviewed the related PRs, I’d especially value your view. I may well have missed part of the reasoning behind these decisions, so please correct me if I’ve got something wrong.
Let me first say that I agree that this is written in a way that is very unclear, and we need to fix that.
The intent with the browser support, specified in 25.0.0 release notes and on the docs page more or less as
Desktop browser
Chrome (evergreen).
Firefox (evergreen).
Firefox Extended Support Release (ESR).
Safari 17 or newer (latest minor version in each major series).
Edge (Chromium, evergreen).
is that as browser versions keep updating and support is dropped rapidly, we should also be moving forward. The meaning of “evergreen” is that we would support only the latest version, which is the version most people are on pretty quickly after its release. Of course not in the way that we would drop Chrome 152 support the day Chrome 153 is released but it states the intent. Similarly we interpret Firefox ESR as an evergreen release, just its creators seem to do:
The ESR version will also have an overlap of at least 12 weeks between the release of a new ESR version and the end-of-life of the previous ESR version.
This means that today, only Firefox ESR 153 (and 140 being phased out) is really supported by Mozilla. With the mentioned exception of Firefox ESR 115 - which is apparently special because of Windows versions. Firefox ESR 140 is end of life in roughly a month according to Firefox ESR schedule
Then we have the special case of Safari which is special because of how Apple holds back new versions from some users and keep supporting Safari 17 even though Safari 27 is out.
If we translate this to what the situation was when Vaadin 25.3 was released, we would get roughly
Chrome 154+
Edge 154+
Firefox 157+
Firefox ESR 140+
Safari 17.6, 18.6, 26.6, 27
Now updating browser support in maintenance releases - I don’t think anybody would like that. But for minor releases, it should be fine as the world is moving forward.
But as said, we should really write this in release notes and in docs in a better way.
Finally, related to your current dilemma, you can probably override the “too old” page check and the build.target in vite.config.ts and see if it works on older Firefox versions. The popover functionality we earlier checked for is unlikely polyfillable but everything else might be made to work automatically.
Fair point, users on Windows 7/8/8.1 are only a small minority. And to be clear: my customer fully supports requiring modern browsers. Dropping ESR 115 itself isn’t the problem.
What hurt was the surprise. Our 1st and 2nd level support had no idea and were suddenly facing messages like: “The application doesn’t work at all and tells me to upgrade my browser. Every other website works, and my browser is up to date, it was updated just last week. What on earth are you doing?”
Had we known in advance, we could have announced the change inside the application and briefed the support team. That’s really my point: not the decision itself, but that a change like this deserves a clear notice in the release notes or the upgrade guide.
thanks a lot for the quick and open reply, and for acknowledging that this needs to be clearer. Our statistics show that most users are on recent browsers, which matches your explanation of “evergreen”. Unfortunately, a few users, and they complain loudly, are forced by their IT to use older browsers. Locking them out without warning doesn’t make life easy for 1st and 2nd level support.
Your translated list for 25.3 is exactly what I was missing. Having such a list in the release notes of each minor, and on the compatibility page, would have avoided our surprise completely, and it would give us something concrete to share with our customer’s support team.
One related thought: since 25.3.0, browsers like Firefox ESR 128 or Safari 17.0–17.4 are effectively no longer supported, as the new build target excludes them, so some styling, colors or features may silently break. PR vaadin/flow#26193 now turns this into a hard block with the “too old” page in a 25.3 patch release. I think that’s the right outcome, but so far neither step has been communicated, and for users who could still open the app before, the patch will be the first visible change. A clear note in that patch’s release notes would help teams prepare their users.
Regarding our dilemma: thanks for the hint. Since popover can’t be polyfilled, we’ll stay with the check and instead ship our own browser-too-old.html in the customer’s design, with a friendly explanation. That hook is very handy. Maybe it deserves a short mention in the docs as well, since others will likely want to customize that page too.