Make sure Element Web works with Firefox ESR

olberger commented 3 months ago

Your use case

It seems (given the discussion in https://github.com/element-hq/element-web/issues/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

andrewshadura commented 2 months ago

So a week of time of your users is eaten instead. Thanks!

t3chguy commented 2 months ago

So a week of time of your users is eaten instead. Thanks!

Sorry I'm not going to insubordinate because a user asks me to be.

erebion commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

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 commented 2 months ago

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

ilf commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Sure, but who is behind that page?

langleyd commented 2 months ago

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 commented 2 months ago

@langleyd Thank you!

wodny commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

element-hq / element-web