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

oliversalzburg commented 3 months ago

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

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

t3chguy commented 3 months ago

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

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

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

same with Opera

t3chguy commented 3 months ago

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

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

you could/should use the passphrase

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

oliversalzburg commented 3 months ago

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

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

andreymal commented 3 months ago

having access to sane Web APIs shortly after they are available

Why do you need them?

t3chguy commented 3 months ago

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

andreymal commented 3 months ago

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

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

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

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

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

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

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

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.

bleve commented 2 months ago

Also centos-stream, rhel and all rhel clones default to firefox-esr. Please add support.

opk12 commented 2 months ago

The Debian package status can be monitored here on tracker.d.o under news.

Sadly, the distro's reproducible package is the only option for the privacy-minded users, as mozilla.org's binaries are non-reproducible per bug 885777.

mind-zz commented 2 months ago

Another voice encouraging "support Firefox ESR". My setup was working last week, then just suddenly stopped. A whole year might be a long time in web development terms, but it's quite short in user terms. I'd rather not have to be a sysadmin every time Doubleclick creates a new browser "feature".

Furthermore, why is there no option to continue using the version of Element that I had been using, before support was dropped?

t3chguy commented 2 months ago

Furthermore, why is there no option to continue using the version of Element that I had been using, before support was dropped?

Because the next time your browser loads that webpage the files necessary for the app are no longer available on the webserver, only the new version is. If someone wants to contribute some service worker magic to support multiple versions then great. Also keep in mind you can't roll back from 1.11.70 because the Rust Crypto database format changed and it is irreversible.

mind-zz commented 2 months ago

If someone wants to contribute some service worker magic to support multiple versions then great. Also keep in mind you can't roll back from 1.11.70 because the Rust Crypto database format changed and it is irreversible.

I'm not wanting to roll back, but rather to keep using the version that was working before the nonconsensual upgrade. In a sane world this would be doable with subdirectories for app versions, but I have no idea if that works in the current world.

t3chguy commented 2 months ago

In a sane world this would be doable with subdirectories for app versions, but I have no idea if that works in the current world.

Yes a system where the path always contains the version would work though would require users to update any bookmarks they have, and going to a link in their history could corrupt their database as they'd be inadvertently rolling back. This would complicate hosting as docker hosting would go out of the window unless we baked in an increasing amount of versions into the image.

risicle commented 2 months ago

Lesson: if element is working for you and asks whether you want to upgrade, always say no - especially as there doesn't appear to be any rollback mechanism.

theres-waldo commented 2 months ago

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

Note that a new ESR spends some time being on Debian unstable before being rolled out to Debian stable.

If I'm reading the package tracker correctly, ESR115 was rolled out to Debian stable on 2023-10-07, over 3 months after the initial release (whose date according to https://whattrainisitnow.com/calendar/ was 2023-07-04).

Therefore, I don't think that "just wait for the new ESR" constitutes a solution here.

tve commented 2 months ago

I'm another user that got stranded with yesterdays update. Please support Firefox! It's actually not working on vivaldi either (different problem). I'm not using chrome/chromium for this. The Matrix is dead 👎🏻

Update: https://hydrogen.element.io/ works great in Firefox!

wetneb commented 2 months ago

I guess I'll cancel my Element One subscription then, since I can't use it anymore? Sad, it was pretty convenient.

BrenBarn commented 2 months ago

A whole year might be a long time in web development terms, but it's quite short in user terms.

That is the essence of the problem. The stated development policies about insisting on bleeding-edge Web APIs are prioritizing developers over users. That's a good way to build a bad reputation.

isAAAc commented 2 months ago

new esr version today in debian :

# dpkg -l |grep firefox
ii  firefox-esr                              115.13.0esr-1~deb12u1                          amd64        Mozilla Firefox web browser - Extended Support Release (ESR)
ii  firefox-esr-l10n-en-gb                   115.13.0esr-1~deb12u1                          all          English (United Kingdom) language package for Firefox ESR

edit: but no change on my side, still blank page ....

t3chguy commented 2 months ago

@isAAAc that isn't the new ESR. https://whattrainisitnow.com/release/?version=esr the current ESR is 128.0

(Reply copied from https://github.com/element-hq/element-web/issues/27693#issuecomment-2222355317)

langleyd commented 2 months ago

Thanks to all the participants' thoughts and suggestions on this topic.

To recap:

Element Web And Element Desktop’s supported environments are detailed here.
While our team strives to ensure the product functions correctly on the supported browsers we can’t guarantee breakages won’t happen on other browsers, as in this case.
Firefox ESR, in addition to Chrome and Edge extended support releases, have not historically been included in that list. We are currently assessing the possibility of adding support for these but will need some time to conclude the feasibility of this.
In the meantime, ESR 128 has now shipped. For the users affected you can find instructions to install the latest version of ESR here. For debian users this includes instructions to install From Mozilla apt repository. Using these to install firefox-esr rather than firefox in the last step, launching it with firefox-esr -P and selecting your original ESR profile will ensure your original Element session is recovered.
In regards to making it easier for users to know they are on an unsupported browsers:
- We will consider clearer user documentation of the support environments linked from element.io.
- There exists in app messaging to tell users that their current browser doesn't support the capabilities required for Element to function correctly. A bug existed that caused this to display as a white screen. This bug has now been fixed. We will also review the messaging and UX here. If it had worked and had directed users to updating their existing browser to the latest supported version(and we had supported the latest ESR) there would have been a sensible path forward for users.

giplt commented 2 months ago

@isAAAc that isn't the new ESR. https://whattrainisitnow.com/release/?version=esr the current ESR is 128.0

(Reply copied from #27693 (comment))

It is the version that comes with Debian stable, see https://packages.debian.org/stable/firefox-esr

Tortoise17 commented 2 months ago

I have reinstalled Firefox 128 and it worked now perfectly well so far with element on CentOS 9 Stream.

b3 commented 2 months ago

To recap: [...]

In regards to making it easier for users to know they are on an unsupported browsers:

We will consider clearer user documentation of the support environments linked from element.io.

There exists in app messaging to tell users that their current browser doesn't support the capabilities required for Element to function correctly. A bug existed that caused this to display as a white screen. This bug has now been fixed. We will also review the messaging and UX here. If it had worked and had directed users to updating their existing browser to the latest supported version(and we had supported the latest ESR) there would have been a sensible path forward for users.

All that comes very late and is not enough at all userwise.

We were numerous committing to promote privacy Hygiene and best practices, in particular trough Tor Browser use and most notably very strongly through Matrix and Element clients, for instance towards our students, colleagues or any non-computer scientists (i.e. normal) people.

Suddendly, at least for those who start to use app.element.io as a first step they lost all their data and are enable to communicate securely since some days...

...and the only solution so far implies a lot of difficult and technical manipulations, which is a no-go for most of them.

All this shitstorm because of a policy which favors developers rather than users and prioritize bleeding-edge features over stability :-(

Guess what will happen next?

Some clues: they will not trust Element (or Matrix because most of them do not make any differences between the protocol and the tool) anymore and it will be very difficult for now to promote it.

That is the worst case of trust loss ever observed. At least we will be able to use it to teach what not to do.

That is very sad and a real pity.

alphapapa commented 2 months ago

Not supporting the Firefox version shipped in Debian stable is like shooting yourself in the foot. As others have said, it worked the other day (and has for years), and then suddenly it doesn't.

You have to realize that many users don't get to choose the software versions they run on all of the machines they use. Organizations tend to dictate that, and they move and upgrade very slowly. And even those who do don't always have time to deal with this. Right now I needed Element to just work like it did the last time I used it, to send an important business message...but suddenly it doesn't work. So now I have to go and find a workaround. Meanwhile, my email client and server work the same as they did yesterday, and so does my phone, etc.

This is a crucial moment in Matrix's history. Problems like this do immense damage to its reputation; it's very hard to un-convince people, "no, no, it's okay now, you should really start using Matrix again, trust me!" Not one of the users--not one--cares about the underlying Web APIs. They just need this tool to keep working.

So you really need to fix this, and fast. The clock is ticking, and the number of people who are wondering whether they can still trust Matrix is increasing.

@ara4n Are you aware of this problem?

t3chguy commented 2 months ago

Meanwhile, my email client and server work the same as they did yesterday, and so does my phone, etc.

Comparing installed apps to webapps is a bit apples and oranges. The former can leverage your dependency manager to prevent updates when you reach an incompatibility point, they can also pull different builds to different distros. These are not feasible in a webapp serving only static files.

@ara4n Are you aware of this problem?

Matthew already responded in https://github.com/element-hq/element-web/issues/27682#issuecomment-2217590924 with the follow up management response being https://github.com/element-hq/element-web/issues/27684#issuecomment-2222807660

tve commented 2 months ago

Comparing installed apps to webapps is a bit apples and oranges. The former can leverage your dependency manager to prevent updates when you reach an incompatibility point, they can also serve different builds to different distros. These are not feasible in a webapp serving only static files.

This is the weirdest comment I have read in a long time! For decades now the advantage of web apps has been that they work pretty much regardless of the end device and that improvements as well as fixes can be deployed rapidly to all users. You're trying to turn that on its head: sorry, that doesn't make sense.

You deployed an update disregarding compatibility with a significant portion of your user base and you apparently lack the agility to quickly revert this update while you consider your options. That's what's going on here.

alphapapa commented 2 months ago

Comparing installed apps to webapps is a bit apples and oranges. The former can leverage your dependency manager to prevent updates when you reach an incompatibility point, they can also pull different builds to different distros. These are not feasible in a webapp serving only static files.

As a developer, I understand how you feel; I know the modern Web is a quagmire. But, respectfully, not a single user of Element/Matrix cares about any of that. Element (and Matrix) is a tool, and problems like this can wreck its reputation in a moment. As a Matrix client developer myself, I very much want Matrix (and its whole ecosystem) to succeed. That's why I'm trying to emphasize the significance of this issue to you.

https://github.com/element-hq/element-web/issues/27684#issuecomment-2222807660

Firefox ESR, in addition to Chrome and Edge extended support releases, have not historically been included in that list.

That is certainly news to me. I think that if Matrix and Element want to continue to be taken seriously in multi-user environments, supporting browsers' ESR releases is a must. (And many single-user ones as well; I don't want to have to upgrade my browser manually, outside of my distro's supported version.)

And that is another point to keep in mind: these ESR releases are not "a year old" when they are maintained in a distribution like Debian. They are continually updated throughout the distro release's lifetime.

t3chguy commented 2 months ago

You deployed an update disregarding compatibility with a significant portion of your user base and you apparently lack the agility to quickly revert this update while you consider your options. That's what's going on here.

This isn't an issue of agility, it is one of policy. If the decision in management is made to support ESR then we will make the necessary changes to support it. Rolling back is not possible as the same update contained a rust crypto update which featured a migration and doing such would corrupt your rust crypto data stores, causing you to need to log out and back in.

I'm personally trying to push for ESR (and Chrome + Edge Extended Stable) to be added to our support policy but all I can do is discuss it internally and then the decision makers have to evaluate the options in front of them. The table seems to be split at the moment at least amongst the ICs, I have little insight into the thoughts of management at this time.

Edit: I don't mind taking the flak for this given I'm the one that pushed the buttons to make the release but ultimately I'm unable to bring a resolution without buy in from some levels higher than me.

t3chguy commented 2 months ago

And that is another point to keep in mind: these ESR releases are not "a year old" when they are maintained in a distribution like Debian. They are continually updated throughout the distro release's lifetime.

Their featureset is a year old is a more clear way of putting it

alphapapa commented 2 months ago

And that is another point to keep in mind: these ESR releases are not "a year old" when they are maintained in a distribution like Debian. They are continually updated throughout the distro release's lifetime.

Their featureset is a year old is a more clear way of putting it

A year is not very long. Not every device can even upgrade the browser anymore. There are tablets and smartphones filling landfills because one day the user could not load the site he used a device for anymore, even though the device itself was perfectly usable.

I don't mind taking the flak for this given I'm the one that pushed the buttons to make the release but ultimately I'm unable to bring a resolution without buy in from some levels higher than me.

It doesn't sound like you're to blame. I don't know if anyone even is; it probably wasn't foreseen that this would happen. But supporting, e.g. Debian's and RHEL's browsers should be mandatory for any software that wants to be taken seriously nowadays.

alphapapa commented 2 months ago

(FWIW, I'd suggest pinning this issue to the top of the list.)

obfusk commented 2 months ago

Rolling back is not possible

Fair enough. But I find it hard to believe there is nothing at all that can reasonably be done here to help out affected users except telling them to update their browsers. What about adding a temporary polyfill to unbreak Firefox ESR?

As I wrote in https://github.com/element-hq/element-web/issues/27682#issuecomment-2220669673:

Given that the immediate issue for most users here is that Firefox ESR doesn't support Intl.Segmenter, would it perhaps be possible to temporarily add a polyfill for that so it starts working again? Perhaps also show some kind of warning when the polyfill is needed. That doesn't mean you have committed to support Firefox ESR indefinitely, but it would unbreak things for Firefox ESR users and allow much less painful migration to a supported browser/client.

Then you also have more time to figure out whether Firefox ESR can be supported and make sure it's properly communicated to users whether their browser is supported or not so users can switch to a different browser if they need to.

I don't mind taking the flak

I think people have been understandably frustrated at the "well it's not supported so we won't do anything to fix it" messaging from Element, mostly conveyed (though obviously not decided) by you, in these issues. That said, I don't think you're to blame here personally. And I very much appreciate you arguing for supporting ESR.

t3chguy commented 2 months ago

Fair enough. But I find it hard to believe there is nothing at all that can reasonably be done here to help out affected users except telling them to update their browsers. What about adding a temporary polyfill to unbreak Firefox ESR?

Yes, this is likely what would be done if the decision makers deem the project wants to support ESR and other incompatible browsers. There is seemingly no synchronous polyfill you can bundle in due to the main one being WASM but there'd be a way around that.

oliversalzburg commented 2 months ago

I updated my initial response to the topic. I believe the desire for Debian Stable/ESR support is mostly driven from reaction. Using this version of Firefox shouldn't be in anyone's best interest in the first place. If you're using Debian on your Desktop, why do you want an old browser? If you're using Tor Browser and am sensible about security, why are you using a Matrix client that you don't control? I know it sucks, but you have to re-evaluate if this impacts you.

obfusk commented 2 months ago

If you're using Debian on your Desktop, why do you want an old browser?

NB: This is getting OT.

Few people want "an old browser". Many people want or need a stable computing experience, not having to deal with frequent changes in software they depend on. That's the whole point of Debian stable. And it's very much a supported browser.

Now, I do think it would be nice to have regular Firefox available in Debian stable as well, for people that prefer the latest and don't mind frequent changes. Because I'd rather get that from Debian, where everything is built from source and ideally also reproducible. But for a lot of people, especially less technical users like my elderly relatives, stability is important. Changes can affect your workflow or take time getting used to. And Firefox ESR is a perfectly reasonable choice.

element-hq / element-web