Skip to content
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

Make sure Element Web works with Firefox ESR #27684

Closed
olberger opened this issue Jul 8, 2024 · 129 comments
Closed

Make sure Element Web works with Firefox ESR #27684

olberger opened this issue Jul 8, 2024 · 129 comments
Labels
O-Occasional Affects or can be seen by some users regularly or most users rarely T-Enhancement T-Feature Request to add a new feature which does not exist right now X-Community-Supported-Platform This issue occurs in a platform not directly supported by us, but by a community project elsewhere X-Needs-Product More input needed from the Product team

Comments

@olberger
Copy link

olberger commented Jul 8, 2024

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

@t3chguy t3chguy added the X-Needs-Product More input needed from the Product team label Jul 8, 2024
@dosubot dosubot bot added O-Occasional Affects or can be seen by some users regularly or most users rarely T-Feature Request to add a new feature which does not exist right now labels Jul 8, 2024
@t3chguy t3chguy added the X-Community-Supported-Platform This issue occurs in a platform not directly supported by us, but by a community project elsewhere label Jul 8, 2024
@oliversalzburg
Copy link

oliversalzburg commented Jul 8, 2024

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
Copy link

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

@t3chguy
Copy link
Member

t3chguy commented Jul 9, 2024

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
Copy link

alfem commented Jul 9, 2024

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
Copy link

rosemash commented Jul 9, 2024

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
Copy link

isAAAc commented Jul 9, 2024

same with Opera

@t3chguy
Copy link
Member

t3chguy commented Jul 9, 2024

@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
Copy link

isAAAc commented Jul 9, 2024

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
Copy link

rosemash commented Jul 9, 2024

you could/should use the passphrase

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

@oliversalzburg
Copy link

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
Copy link
Member

t3chguy commented Jul 9, 2024

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

@andreymal
Copy link

having access to sane Web APIs shortly after they are available

Why do you need them?

@t3chguy
Copy link
Member

t3chguy commented Jul 9, 2024

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

@andreymal
Copy link

andreymal commented Jul 9, 2024

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
Copy link
Member

t3chguy commented Jul 9, 2024

@issuehaver2
Copy link

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
Copy link

rosemash commented Jul 9, 2024

@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
Copy link

ghost commented Jul 9, 2024

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
Copy link

opk12 commented Jul 9, 2024

@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
Copy link
Member

t3chguy commented Jul 9, 2024

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.

image

@oliversalzburg
Copy link

oliversalzburg commented Jul 9, 2024

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.

@erebion
Copy link

erebion commented Jul 21, 2024

Reverting two prs and doing releases on four projects will eat up most of a day. Can't do that without management signing off on that time.

What would be the best way to let management know about the issue and kindly ask them to allow it to get fixed?

@t3chguy
Copy link
Member

t3chguy commented Jul 21, 2024

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
Copy link

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
Copy link

obfusk commented Jul 21, 2024

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
Copy link

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
Copy link

l0b0 commented Jul 21, 2024

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
Copy link
Member

t3chguy commented Jul 21, 2024

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.

image

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
Copy link

theres-waldo commented Jul 22, 2024

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
Copy link

dadinn commented Jul 22, 2024

image

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
Copy link
Member

t3chguy commented Jul 22, 2024

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
Copy link

@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
Copy link

knarrff commented Jul 22, 2024

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
Copy link
Member

t3chguy commented Jul 22, 2024

@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
Copy link

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
Copy link

erebion commented Jul 22, 2024

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

@ilf
Copy link

ilf commented Jul 22, 2024

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
Copy link

AdamMajer commented Jul 22, 2024

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
Copy link

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
Copy link
Contributor

ptman commented Jul 22, 2024

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
Copy link

erebion commented Jul 22, 2024

Sure, but who is behind that page?

@langleyd
Copy link
Member

langleyd commented Jul 23, 2024

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
Copy link

@langleyd Thank you!

@wodny
Copy link

wodny commented Jul 24, 2024

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
Copy link

  • 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
Copy link
Member

t3chguy commented Jul 26, 2024

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.

image

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

@olberger
Copy link
Author

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
Copy link

timmc commented Jul 26, 2024

@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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Occasional Affects or can be seen by some users regularly or most users rarely T-Enhancement T-Feature Request to add a new feature which does not exist right now X-Community-Supported-Platform This issue occurs in a platform not directly supported by us, but by a community project elsewhere X-Needs-Product More input needed from the Product team
Projects
None yet
Development

No branches or pull requests