Make sure Element Web works with Firefox ESR

[olberger]

Your use case

It seems (given the discussion in #27682, unless the person in charge of support there) that Firefox ESR isn't supported.

Given it has a large user base (enterprise, Debian stable and derived, etc.) it would be very valuable to have it supported.

Have you considered any alternatives?

No response

Additional context

No response

[oliversalzburg]

Updated Response

To be perfectly honest, as a Debian user, I am well familiar with having to install certain software from external repositories or from sources, because the Debian repositories, while stable, don't provide my necessary feature sets.

In fact, if you only install packages from Debian stable repositories, you're leaving yourself vulnerable to issues that stand unfixed in the stable versions of Debian. Stable in Debian terms does not mean more secure or better in any way, especially if you're on Desktop.

Do yourself a favor and just move away from the ESR Release in the Debian repositories.

If you still feel like you have valid reasons beyond that, consider that internationalization, localization, and accessibility probably outweigh your desire to use an ancient ESR to access a version of Element which is apparently not even even under your control.

Previous Comment

Start with the default configuration

You can pick a sound set of versions with the defaults query which is a shortcut for > 0.5%, last 2 versions, Firefox ESR, not dead. It matches recent versions of popular and supported browsers worldwide and includes Firefox Extended Support Release which is updated roughly annually.

The defaults query was thoroughly designed by the Browserslist community. It helps promote best practices and avoid common pitfalls.

From https://browsersl.ist/

Not sure what the best practice was at the time the supported environments were picked, but it seems not ideal today.

[Tortoise17]

For me also it is broken. On firefox it is not working anymore since recent update from yesterday.

[t3chguy]

Not sure what the best practice was at the time the supported environments were picked, but it seems not ideal today.

That would have us support Chrome down to 109, mobile browsers, Opera, KaiOS, UC Browser, and all other things we have intentionally excluded in preference to having access to sane Web APIs shortly after they are available. We have a supported environments thing at the top of our README for a reason. ESR is in a similar boat, being over a year old at this point.

[alfem]

Yes, broken in 115.12.0esr (64-bit).

I use to report this kind of issues in mozilla channel in matrix, but unfortunately it is not possible now.

[rosemash]

I want to reiterate something that was mentioned on #27682: firefox-esr is the main supported browser in Debian stable, which is a massive user base (especially of OSS like matrix). I use the element instance at chat.mozilla.org and was completely unaware firefox-esr was unsupported until I was locked out of my only session half an hour ago. That just doesn't seem right. A debian user can install chromium, but won't be able to verify their new session with their original one.

[isAAAc]

same with Opera

[t3chguy]

@isAAAc Opera has never been a supported environment: https://github.com/element-hq/element-web#supported-environments - it ever working was purely incidental as it supported the necessary APIs at a previous time

[isAAAc]

Opera has never been a supported environment

oh, ok ^^

A debian user can install chromium, but won't be able to verify their new session with their original one

you could/should use the passphrase

[rosemash]

you could/should use the passphrase

I agree, but this situation also shouldn't happen at all to necessitate that.

[oliversalzburg]

That would have us support Chrome down to 109, mobile browsers, Opera, KaiOS, UC Browser, and all other things we have intentionally excluded in preference to having access to sane Web APIs shortly after they are available. We have a supported environments thing at the top of our README for a reason. ESR is in a similar boat, being over a year old at this point.

That's reasonable. I didn't mean to suggest to adopt defaults, but given that ESR is included in it, maybe it's worth considering under these circumstances. I understand not wanting to support an unreasonably large surface of clients, but including them in the Babel downleveling as a best-effort approach to increase usability, seems reasonable to me as well.

[t3chguy]

babel downleveling won't handle things like polyfilling Intl.Segmenter which is the cause for the recent issue

[andreymal]

having access to sane Web APIs shortly after they are available

Why do you need them?

[t3chguy]

To avoid bloating the bundle with a mass of polyfills and points of potential supply chain attack

[andreymal]

mass of polyfills

Why do you need polyfills? According to my grep, Intl.Segmenter you mentioned is not even used (at least in this repo, not sure about dependencies)

[t3chguy]

@andreymal https://github.com/element-hq/compound-web/blob/15eefea5f821d546e6ea687c6da4b10af53b6f81/src/utils/string.ts#L21 & https://github.com/matrix-org/matrix-react-sdk/blob/cd39d91c15a91b8a1be930ef29d95798896a1110/src/utils/strings.ts#L87 (these are both dependencies of element-web)

[issuehaver2]

Adding another voice here to please add support for Firefox ESR. I had no idea this support would cease until I was suddenly locked out of the element web app yesterday, and there wasn't even an error message or anything, just a blank screen. I had to come here to find out what was going on, only to discover I can likely never access any of my old messages again. I'm stressing over this.

[rosemash]

@issuehaver2

Adding another voice here to please add support for Firefox ESR. I had no idea this support would cease until I was suddenly locked out of the element web app yesterday, and there wasn't even an error message or anything, just a blank screen. I had to come here to find out what was going on, only to discover I can likely never access any of my old messages again. I'm stressing over this.

If you direly need to recover your old session if you're using a broken element instance, you can fix it by installing the latest build of firefox (f you're on debian there are instructions to add mozilla's repository here: https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions)

Then from the new browser, go to to about:profiles, and change to the firefox-esr profile to restore your old cookies. Just make sure when you uninstall firefox-esr it doesn't remove profiles (apt remove doesn't on debian 12, I tried it) so you don't lose the session.

It's not a permanent solution but you haven't lost anything.

[ghost]

Adding my voice here as well, because it is deeply important to me:
Yes, please absolutely add Firefox ESR to the list of supported environments.

Tons of people (not to mention all Debian users by default; and all Tor Browser users) are on the ESR branch, because - believe it or not - there's people out there that prioritize stability over bleeding-edge features.

Aside from stability, it's a really bad look for a messenger whose focus are privacy, freedom, & security to not work in Tor Browser.

[opk12]

@t3chguy

That would have us support Chrome down to 109, mobile browsers, Opera, KaiOS, UC Browser, [snip]

No, supporting the long-term release of one of the two major engines, or vendors if you prefer, is a very specific request. It does not follow that any random browser should be supported.

[t3chguy]

No, supporting the long-term release of one of the two major engines, or vendors if you prefer, is a very specific request. It does not follow that any random browser should be supported.

The suggestion I was replying to was to use the browserl.ist defaults set which most definitely would have the exact impact I outlined.

[oliversalzburg]

Good news. Seems like the Firefox release today is also the new ESR. https://whattrainisitnow.com/

To upgrade Firefox away from the ESR, the documentation suggests, among other options, to follow the Mozilla guide on how to use their APT repository.

[t3chguy]

They are aware hence the response here much earlier. It is going through the processes, you just have to wait for them to come back to you with a decision.

[alphapapa]

They are aware hence the response here much earlier. It is going through the processes, you just have to wait for them to come back to you with a decision.

Respectfully--and not to criticize you or point fingers at anyone in particular--this seems like an "all hands on deck" kind of decision that ought to be made within a day or so. For every person complaining here about breakage, there are who-knows-how-many others who just stopped using Matrix instead, because they neither know nor care about this place and how Matrix works behind the scenes. The potential damage to Matrix's long-term reputation caused by this breakage--I think it can hardly be exaggerated. The urgency here ought to be something like one level below "emergency."

[obfusk]

AFAIK "the Element devs are stuck doing other paying-customer stuff as their day job". So without a paying customer, I doubt this will get fixed any time soon. I personally think it's absurd that this isn't considered high priority, but devs don't owe anyone free labour and Element as a for-profit company has it's own priorities that do not necessarily align with ours. I do wish they'd be more upfront about that, a "sorry we'd like to fix this but we can't pull people off their day jobs to do it" would still suck but at least it wouldn't just leave users waiting.

[jgoerzen]

I would just like to add here that Firefox ESR is not just for Debian. It's really a key part of Mozilla's enterprise strategy. Firefox has two update channels: "rapid release" and ESR. Firefox 115 IS one of the two most recent ESR releases (though not one of the two most recent Rapid releases). Note that ESR and Rapid releases are not actually the same, even on day zero when they come out.

Why is ESR important? Imagine you're supporting 100,000 clients. Your users run various mission-critical webapps. They may have custom plugins. If you can only get security updates by upgrading, that is a nightmare; some of the apps may be broken by updates, etc. So you have ESR. These organizations can still maintain security while having a more achievable 42-week window for validating and updating.

Another scenario would be: consider if you're supporting not very computer-literate relatives at a distance. Grandparents, say. Are you going to give them something that might change how it looks and behaves every month, or something that you can upgrade for them when you see them twice a year (and stay secure between that anyhow)?

My point here is that as Element is trying to sell the Matrix ecosystem into businesses -- something I wish them much success with -- they are not going to be able to do so with the kind of attitude evinced here. Enterprises simply cannot easily upgrade their browser to new feature releases every month. Not only that, but 115 ESR IS one of the two most recent Firefox releases.

[l0b0]

One big reason to run ESR is policy templates, many of which are not (and are not expected to ever be) supported on mainline Firefox; see for example this discussion. I'm running ESR to have this much more sane way of configuring Firefox than profile.json, and I expect so are many workplaces where enterprise profiles are in use.

[t3chguy]

So you have ESR. These organizations can still maintain security while having a more achievable 42-week window for validating and updating.

I do wish that ESR would stick to its 42 week window though.

The above is between ESR115 and ESR128

It would certainly unblock a lot of things. If we ended up needing a feature which ESR lacked and had to tell a customer, sorry we can't ship it for until next year or maybe the year after that would likely sink a deal. Not having actual dates to work off like other LTS offerings (Chrome & Edge Extended Stable) is a bit crud. And this is also ignoring the (as far as I can tell) lack of a solid timeframe of how long distros like Debian need to ship a given ESR from the moment it lands. If we could say its 42+12 weeks and never a moment more that'd at least be a starting point.

[theres-waldo]

Not having actual dates to work off like other LTS offerings (Chrome & Edge Extended Stable) is a bit crud.

Firefox ESR has been on a pretty stable annual cadence, with EOL dates being around September of a given year:

• Firefox ESR 91 EOL: 2022-09-19
• Firefox ESR 102 EOL: 2023-09-25
• Firefox ESR 115 EOL: 2024-09-30

(I'm basing these on https://whattrainisitnow.com/calendar/, with the EOL date being the last day of the release cycle of the last minor version for a given ESR, i.e. the day before the next release after that.)

[dadinn]

Wait, are you saying this is really just a vendor lock-in product disguised as OSS?
The FLOSS community is essentially their guinea pig beta-testers.

[t3chguy]

Firefox ESR has been on a pretty stable annual cadence, with EOL dates being around September of a given year:

Right, so their "average 42 weeks" is a farce? https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel

receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks.

[andrewshadura]

@t3chguy, I just wanted to point out comments like the above you made are very inappropriate and make a really bad impression about Element (an impression I hope isn’t true).

@ara4n, how come this has been dragged along for two weeks? This is extremely disappointing.

[knarrff]

Right, so their "average 42 weeks" is a farce? https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel

A comment about ESR releases of someone else being later than originally planned, by someone who doesn't even have them? Really?

[t3chguy]

@t3chguy, I just wanted to point out comments like the above you made are very inappropriate and make a really bad impression about Element (an impression I hope isn’t true).

I think I'm granted my own opinions outside of my working hours

[andrewshadura]

Anyone can have any opinions, but that does not mean the comments they make may be inappropriate and rude, which that comment undoubtedly was.

[erebion]

Just calm down, everyone. Generating more comments than people can read will not help us get the issue solved.

[ilf]

If you're using Tor Browser and am sensible about security, why are you using a Matrix client that you don't control?

That's a poor definition of "security". Tor Browser does many things, among them censorship circumvention. Just one example: https://app.element.io/ is blocked in Iran. Tor Browser makes it accessible again.

[AdamMajer]

Enterprise distros would generally follow ESR. ESR has overlap of support upstream allowing for migration from one ESR to next. This happens for any software with long term support. For firefox, there are currently,

Firefox 115.13.0esr and
Firefox 128.0esr

solid timeframe of how long distros like Debian need to ship a given ESR from the moment it lands. If we could say its 42+12 weeks and never a moment more that'd at least be a starting point.

Long time ago, there were attempts to backport browser fixes but this doesn't happen anymore. EOL of ESR by Mozilla can be assumed to be cut-off date for the browser being supported by distros.

[theres-waldo]

Firefox ESR has been on a pretty stable annual cadence, with EOL dates being around September of a given year:

Right, so their "average 42 weeks" is a farce? https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel

receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks.

That does seem to be out of date. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1909292 to get it updated.

[ptman]

https://riots.im/ can be handy for using older element-web versions if you don't want to serve an older version yourself (tarball + https server)

[erebion]

Sure, but who is behind that page?

[langleyd]

Thanks again to all for the feedback and thoughts on this topic.

Until now Firefox ESR was outside of our support policy, and was therefore not a browser we tested for. This coupled with a recent breakage of the “Unsupported Browsers” screen, meant users were left in a broken state. Apologies to those users left in this state during the last release while a decision was made on the possibility of adding support.

Element has decided to add support on a best effort* basis for the latest Firefox ESR and Chrome/Edge Extended Stable browsers, the timeframe for which will be extended until the new version of Firefox ESR lands in Debian stable plus one additional release cycle(2 weeks). We have fixed the Unsupported Browsers screen and have also added a code change for the upcoming Release Candidate that will allow users on Firefox ESR 115 to continue to the product from the Unsupported Browsers screen. We will also be improving the in-app experience to better inform users ahead of time that support for their browser will cease.

* What does “best-effort” mean in practice?

• The wider Element Products(including Element Call and the Enterprise Server Suite) do still not officially support these browsers. Element Call currently works with Firefox ESR 128 but a break in the future may be unavoidable (E.g. If Element called needed to use a modern api to support End-to-End encrypted VoIP).
• The element web project and its contributors should keep the client functioning and gracefully degrade where other sibling features like Element Call may not function.
• We will invest in tooling and processes to try ensure the extended support browsers continue to function for the period outlined above though this may be challenging; for example our primary tool for such testing, Playwright, does not currently support older Firefox releases (see https://github.com/microsoft/playwright/issues/31163).

[alphapapa]

@langleyd Thank you!

[wodny]

Firefox ESR has been on a pretty stable annual cadence, with EOL dates being around September of a given year:

Right, so their "average 42 weeks" is a farce? https://support.mozilla.org/en-US/kb/choosing-firefox-update-channel

receives major updates on average every 42 weeks with minor updates such as crash fixes, security fixes and policy updates as needed, but at least every four weeks.

That does seem to be out of date. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1909292 to get it updated.

The SUMO page has been updated to declare 52 weeks on average.

[TurtleWilly]

• 11 of these instances are currently not updated automatically/periodically anymore

I had to stop updating after 1.11.26, because compatibility with Firefox 78.15.0esr was broken. (That's the most up-to-date browser I can run w/o having to buy new (Mac) hardware). 😎

Personally I would expect better in regards of backwards compatibility from both Element (should support older ESR releases too) and Firefox (should support older versions of (mac)OS too).

All this insane level of bleeding edge and security theater forces poor folks like me to run with way older version that are like "not secure" at all. What is this madness? What is the most strange thing to me: these days this is mainly driven by OSS based projects. There's a lack of community approach regarding backwards compatibility that avoids discriminating people that just can't afford this rat's race. 😱 Oh and dare when you report an issue in such case then you'll most likely be looked at like you're crazy and come from Mars. I'm quite sure some will raise an eyebrow about my comment here too: "WTF doe this person wants with Firefox 78ESR support now?".

So what? You have to provide a few extra bytes of polyfill to support the latest Firefox ESR (115)? What's the big deal? Why is that something even to not consider? I do not understand this at all. If I was in charge of Element it certainly still would work perfectly fine with Firefox ESR 78 (probably even a step older).

Anyway… just to give you another perspective… 😇

[t3chguy]

So what? You have to provide a few extra bytes of polyfill

Not everything is polyfillable, e.g. ESR 115 won't support anything relying on WebRTC insertable streams as a polyfill is not possible.

Which renders things like end-to-end encrypted video conferencing broken

[olberger]

Wow, this was by far the longest thread under an issue I ever filed ;-)

Thanks for the responses from the management, and hopefully, most of the participants learned something in those eventful times.

[timmc]

@t3chguy For me, lack of video support would also be pretty reasonable tradeoff for being able to use a 4 year old browser. But I think your point stands—there are also cryptography APIs that are hard to replace with polyfills (in particular, anything having to do with RNGs.)