Intl.Segmenter is not a constructor - unable to use Element Web on Firefox ESR 115.12.0esr (64-bit)

[wodny]

Steps to reproduce

1. Try to open the app in Firefox ESR

Outcome

What did you expect?

I expected the app to work.

What happened instead?

Got an exception in console:

Uncaught TypeError: Intl.Segmenter is not a constructor
    node_modules bundle.js:2
    l tslib.es6.mjs:369
    tsx MediaDeviceHandler.ts:89
    l tslib.es6.mjs:369
    ts MatrixActionCreators.ts:369
    l tslib.es6.mjs:369
    ts MatrixClientBackedController.ts:30
    l tslib.es6.mjs:369
    tsx SettingLevel.ts:20
    l tslib.es6.mjs:369
    ts ConfigSettingsHandler.ts:68
    l tslib.es6.mjs:369
    tsx IntegrationManagers.ts:184
    l tslib.es6.mjs:369
    tsx DevtoolsDialog.tsx:147
    l tslib.es6.mjs:369
    ts RecorderWorklet.ts:1
    l tslib.es6.mjs:369
    c tslib.es6.mjs:369
    O tslib.es6.mjs:369
    <anonymous> tslib.es6.mjs:369
    <anonymous> tslib.es6.mjs:369

This API is supported since Firefox 125. I hope that dropping support for Firefox ESR is just an untested (sic!) dependency problem and not a conscious misguided decision.

Operating system

Debian Linux (bookworm)

Browser information

Firefox 115.12.0esr (64-bit)

URL for webapp

https://app.element.io/

Application version

Can't say - it's not starting

Homeserver

matrix.org

Will you send logs?

No

[olberger]

This happens to me on Debian testing 117.0 too

[t3chguy]

As per https://github.com/element-hq/element-web#supported-environments we only support the last 2 major versions of each of the listed browsers, for FF this means 126 & 127.

[olberger]

Uh, it's a joke, is it ? You intend to get rid of a large user base, don't you ?

[t3chguy]

I'm just an individual contributor, I didn't write the policy. I'm merely linking you to it as it says

Issues only affecting unsupported environments are closed

[olberger]

I'm just an individual contributor, I didn't write the policy. I'm merely linking you to it as it says

Issues only affecting unsupported environments are closed

Please consider how rude this is to close other users' issues :-/

[t3chguy]

It is my job, I am tasked with triage and applying the policies and rules that are set. One of which as linked above says

Issues only affecting unsupported environments are closed

Therefore I have to close it

[wodny]

As per https://github.com/element-hq/element-web#supported-environments we only support the last 2 major versions of each of the listed browsers, for FF this means 126 & 127.

The ESR's are major versions from a dedicated branch which is important for enterprise use and security-wise. By dropping support for ESR's you are dropping Debian support.

[t3chguy]

The support policy never claimed support for ESR though. https://github.com/element-hq/element-web#supported-environments it says Last 2 major versions of ..., Firefox, not Firefox ESR. The enterprise can keep using an older version of Element until they can upgrade to a browser which does not lack the necessary APIs.

[wodny]

I'm just an individual contributor, I didn't write the policy. I'm merely linking you to it as it says

Issues only affecting unsupported environments are closed

Please mention the policy authors here so they can rethink their position. This is too huge of a problem to discard in 5 minutes.

[t3chguy]

@langleyd cc as my manager

[olberger]

@t3chguy Would you mind reopening until someone knowledgeable is able to judge ?

[t3chguy]

Unfortunately not, given the policy says it must be closed. Sorry

---

Not being able to use features for an additional approx 42 weeks based on the Firefox ESR update schedule would massively slow down feature development and be a direct detriment to our funding.

Even Mozilla themselves suggest you use the Rapid Release (Firefox default) versions

[olberger]

Unfortunately not, given the policy says it must be closed. Sorry

Being stubborn won't help in any way. Can we appeal ?

[wodny]

The enterprise can keep using an older version of Element until they can upgrade to a browser which does not lack the necessary APIs.

Which URL should I use to use an older Element version?

[t3chguy]

Being stubborn won't help in any way. Can we appeal ?

Its an open source project driven by a commercial entity, we are driven by a product team which takes input from management & our customers.

Which URL should I use to use an older Element version?

One which you host yourself based on the tarballs or docker images available, I'd be surprised any enterprise would be using *.element.io infrastructure given it'd be an additional privacy policy in the mix and not allow for custom configuration

[olberger]

I'm just an individual contributor, I didn't write the policy. I'm merely linking you to it as it says

Issues only affecting unsupported environments are closed

Please mention the policy authors here so they can rethink their position. This is to huge of a problem to discard in 5 minutes.

I just filed:
#27684 so as to be sure the policy doesn't prevent Firefox ESR to be supported.

[obfusk]

Debian stable uses Firefox ESR. This means Element Web just broke for plenty of regular users, not just "enterprise".

[wodny]

@t3chguy:

I'm just an individual contributor, I didn't write the policy. I'm merely linking you to it as it says

In this case it seems you are a very specific individual contributor that made an autonomous decision and switched from graphemer to Intl.Segmenter which is the reason of the problems. One of the users even left you a warning about it and offered an alternative:

Any wins against Segmenter directly?

Yes for runtime perf and compatibility (if matter). That's the same reason graphemer was originally used.

Intl.Segmenter is still too new (especially in Firefox) and underperforms user implementations. It comes from inefficient binding to icu4c, both in Chrome and Safari. (To be fair, they improved a lot in very recent versions)

[t3chguy]

autonomous decision

It was discussed internally, along with confirmation that it is supported by our supported environments. ESR was not considered whatsoever at this time given it isn't listed as a supported environment.

This isn't the first ESR-related breakage for similar reason. The ESR release is said to be every ~42 weeks, the currently major of ESR is over a year old, which locks out a lot of Web features.

One of the users even left you a warning about it and offered an alternative in #12617:

The warning was that it is too new especially in Firefox, but again complied with our support policy by over 150%. The primary winning is smaller bundle size. The first driver of this was https://github.com/element-hq/compound-web which moved away from graphemer as graphemer was ~30% of the entire matrix-authentication-system bundle which depends on compound-web. Given that Compound now used Intl.Segmenter the choice to follow the same route here was basic, as we too depend on compound-web.

[wodny]

This isn't the first ESR-related breakage for similar reason. The ESR release is said to be every ~42 weeks, the currently major of ESR is over a year old, which locks out a lot of Web features.

Firefox 128 ESR is scheduled to release tomorrow. Hopefully, it will appear in Debian soon. Couldn't the change wait a couple of weeks until the new ESR is released instead of breaking the app?

The primary winning is smaller bundle size. The first driver of this was https://github.com/element-hq/compound-web which moved away from graphemer as graphemer was ~30% of the entire matrix-authentication-system bundle which depends on compound-web.

How much was the Element Web bundle/whole downloaded code size reduced?

[obfusk]

Last 2 major versions of Chrome, Firefox, and Edge on desktop OSes
Linux versions for desktop devices that are actively supported by the OS vendor and receive security updates

I understand (though I do not quite agree with) the reasoning here. And can see how this is being interpreted as Firefox ESR not being supported.

But as Firefox ESR is the only officially supported version of Firefox and receiving regular security updates on Debian stable (and regular Firefox is not available unless installed via e.g. flatpak) I think it's very much not obvious (and very much not user-friendly) that Debian stable is not supported by element web.

[t3chguy]

Mozilla themselves recommend "Rapid Release" (default) over ESR including for Enterprise:

[t3chguy]

And can see how this is being interpreted as Firefox ESR not being supported.

It is also codified as such: https://github.com/element-hq/element-web/blob/develop/babel.config.js#L7-L12

[t3chguy]

We don't have the bandwidth to maintain multiple feature branches to maintain multiple releases like this and no QA team. The team is literally 3.5 people who each have to work on different projects. Plus the above wouldn't work if an Enterprise was only updating every couple of months, unless the 1.2.1 release was done many months before 1.3.0. Its a crap situation but it is what it is. It doesn't help that no one reported the issue with ESR until 4 days ago, many days after that change landed on develop & staging.

[t3chguy]

The fix for the feature detection not working causing a white screen has now landed and will be included in the next release cycle

[rosemash]

I was just locked out of my account because of this this. I was using the official element instance hosted at chat.mozilla.org, refreshed, and suddenly I can no longer access my session. This is the first I've heard of this incompatibility, there was no warning. I am on debian stable and not sure how to proceed.

[t3chguy]

I have raised the chat.mozilla.org issue to the EMS team, it'll likely be a case of the owners of the Mozilla instance needing to ask for a version rollback for them to have wider compatibility if they desire

[alfem]

@alfem sounds like you would be unaffected then? Just stay on the last incidentally compatible version until the overdue ESR ships?

I am affected, of course.
How can I stay on the last version? I noticed the error after updating the webapp. AFAIK I can not undo that.

I commented this issue in mozilla-es matrix channel (using Chrome) and they are moving this internally in their webcompat group.

[t3chguy]

@alfem sounds like you didn't follow your own policy of

need to check software updates carefully

Websites in general can only be downgraded by the people which control them, unless you can convince your browser to pull out some old cached copy but that seems unlikely

[alfem]

@alfem sounds like you didn't follow your own policy of

Yes, I manage linux deployments for my government. But a webapp can be updated without supervision. Perhaps you are suggesting me to block Element webapp for our users, and move to a serious native app.

[t3chguy]

I was suggesting maintaining your own instance of element-web (which is purely static hosted web files so fairly trivial) that you uphold to the same policy if you expect it to remain compatible in the same manner as the rest of the system, or a native app, that's your call.

[rosemash]

Respectfully I don't think it's reasonable to expect people using a major mainline distro to simply hold back updates for element in order to remain compatible. Stable release cycles favor few feature changes, but that's not the same thing as being outdated.

[ara4n]

Hi folks - speaking as the guy in charge of Element; while Firefox ESR isn't technically a supported platform and we don't test it (hence this breakage), we obviously don't want to break a large set of users. We're looking into how best to deal with this. Meanwhile, please calm down and keep this issue for tracking resolution (otherwise I'll lock it).

[t3chguy]

@ara4n #27684 is the issue for finding a resolution

[theres-waldo]

Note: for Firefox ESR115 users on Debian-based systems who are willing to upgrade from ESR115 to the latest stable (non-ESR) release (currently Firefox 128) from Mozilla's package repository, the following steps can be used to upgrade your existing browser profile (including your existing Element session). This allows you to continue to use your existing Element session even if it was the only one:

1. Follow the steps at https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions to install Firefox 128 from Mozilla's package repository.
2. In your Firefox ESR instance, go to about:profiles and take note of the name of the currently running profile. (It will be marked with "This is the profile in use and it cannot be deleted".) If you haven't created additional profiles, this will typically be default-esr.
3. Close your Firefox ESR instance.
4. Run firefox -p. This starts the newly installed Firefox release and opens the profile selector.
5. Select the profile name you noted down above. Ensure "Use the selected profile without asking at startup" is checked.
6. Click "Start Firefox".

Note that once a profile is upgraded from ESR to Release, it likely cannot be opened with ESR again.

[divVerent]

Maybe another constructive option here would be: if the web app loads but the current browser is not supported, instead of just showing an error page, the error page should provide sufficient options to export the data so it can be used in another browser.

This means the following functions should be available:

• Either:
  • Verify other devices/browsers
• Or:
  • Generate a new recovery passphrase (i.e. reset key backup)

As long as either of these things is possible even on unsupported browsers (ideally even on very old ones, like, all that Element ever worked on - this can be achieved by implementing these only using very basic functionality), this means nobody will lose their data over this, as the crypto keys in the local profile can still be migrated to another browser or device. Which is all that really matters.

This is better than just offering Firefox ESR to Firefox migration, as many users cannot or are not able to install software from "remote" sources like other websites, but might be bound by their pre-configured package sources by a system administrator; thus, it'd be crucial to also have the option to migrate from Firefox ESR to, say, Chromium, or from a too old Chromium to Firefox. Also, some users may be able to upgrade to a different version of a browser but it'd have to be in a Snap or Flatpak then - standard instructions like the above won't help much then either.

In addition, it'd make sense to show the above instruction by @theres-waldo as well, or maybe a link to a wiki page detailing various ways to migrate.

[t3chguy]

Maybe another constructive option here would be: if the web app loads but the current browser is not supported, instead of just showing an error page, the error page should provide sufficient options to export the data so it can be used in another browser.
...
As long as either of these things is possible even on unsupported browsers (ideally even on very old ones, like, all that Element ever worked on - this can be achieved by implementing these only using very basic functionality), this means nobody will lose their data over this, as the crypto keys in the local profile can still be migrated to another browser or device. Which is all that really matters.

This is great in theory but in practice quite difficult. To Verify, Export, etc etc you would need to load up quite a lot of code. The init code, React, UI, React SDK, JS SDK, Rust Crypto, WASM, etc. Unless we were to replace all of those with a 2nd implementation which reimplemented all the things in lower level code which would increase development friction, brittleness and need stringent additional testing. The code would keep growing in complexity also as it would need to comprehend all database formats as db migrations occur, and given the low level nature it'd end up being a rather large project all on its own. Not at all impossible but infeasible for a team of 3.5 people with ongoing project obligations already prescheduled for many months ahead.

[divVerent]

Then maybe we need a clear warning when using Element about the browser support policy, and that if the user cannot abide by it by using officially supported browsers, they WILL lose all their data and verifications, and thus should REALLY add a second device or make sure they REALLY never lose the recovery key. Maybe should even nag people once per month to check if they still know where their recovery passphrase is.

Like, I'm a software engineer, I know to not ever rely on data stored in web browsers. But most end users do not, and given this policy of Element - which is IMHO very surprising from a user perspective, I personally thought we've long moved past "Best viewed with Internet Explorer 4 on 800x600 on an Pentium MMX with a Geforce 2 MX" - this deserves a strong warning to end users.

Arguably the warning should be done anyway, as it is rather easy to nuke one's browser profile with features like "clear browsing data".

[obfusk]

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.

[superkuh]

I'd like to add that my 12 group security key I had saved in a text file doesn't work, "Could not enable key backup: Bad MAC.", so until I can get my older Firefox install running element.io client again I can't even access my account history with other clients like Hydrogen Chat. Thanks for the zero warning it'd just stop working. At this point I might as well give up on matrix protocol entirely.

[alphapapa]

I'd like to add that my 12 group security key I had saved in a text file doesn't work, "Could not enable key backup: Bad MAC.", so until I can get my older Firefox install running element.io client again I can't even access my account history with other clients like Hydrogen Chat. Thanks for the zero warning it'd just stop working. At this point I might as well give up on matrix protocol entirely.

FWIW, my saved key works when pasted into a fresh browser instance.

[hartnegg]

If you knowingly break compatibility with the latest ESR version, even without warning anybody, you should at least change your webpage "Supported Environments". It does not, but should specificly say, that you support only the Rapid Release versions.

[knarrff]

It seems that mostly this comes from someone, intentionally or not, not specifying ESR versions as supported and, probably someone else, using that statement to argue for a change that locks out large parts of the user base. To me, this suggests that original problem is the intended list of supported browser versions: who can make decisions about that and how can we reach/influence those people - making them aware that this is ruinous to their project?

[divVerent]

Also, I think we're conflating two issues here:

• The Element client's code base: that can of course have any kind of browser requirements it wants, and it's up to admins to update or not, etc. - here it'd be nice to simply declare new API requirements so admins can make the decision in an informed manner.

• The app.element.io web client - this should be administrated in a way to minimize disruption. E.g. before a browser-breaking change is rolled out, users should be notified some weeks in advance so they are given time to export their data or upgrade their browser.

Then there's also the third issue that the browser requirements at https://github.com/element-hq/element-web?tab=readme-ov-file#supported-environments aren't clearly enough written - most Firefox ESR users probably think they ARE running one of "Last 2 major versions of Chrome, Firefox, and Edge on desktop OSes".

So maybe this should be worded clearer to explicitly exclude ESR?

But also, I've never seen these requirements ever before this thread. Signing up at app.element.io doesn't show them. Maybe it should?

[knarrff]

So maybe this should be worded clearer to explicitly exclude ESR?

I think the point a lot of the commenters here tried to bring across is that it ought to explicitly include, not exclude them.

[melroy89]

Unable to use Element Web with Floorp, because you dropped support of ESR. This is insane.

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

[rosemash]

@langleyd Much appreciated!