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: https://github.com/element-hq/element-web/issues/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 https://github.com/element-hq/element-web/issues/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

[wodny]

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

On the other hand - a quote from https://browsersl.ist/ mentioned in #27684:

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.

[obfusk]

I have been using element web on Debian with Firefox ESR for years. It has never once warned me my browser was unsupported. Nor have I heard such from other Debian users. And most websites work perfectly fine. I do not consider it unreasonable for users to expect Firefox ESR to work (which it has for years).

And now element web simply doesn't load. At all. Which also means users cannot simply switch to a different browser or client if they need the existing session for verification and decrypting existing messages.

[t3chguy]

On the other hand - a quote from browsersl.ist mentioned in https://github.com/element-hq/element-web/issues/27684:

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 supports 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.

It has never once warned me my browser was unsupported.

This is because we use feature detection rather than user agent parsing, as the latter is horrible and often misled by UA faking extensions. So we never look at what browser you run, only if it supports the features we need.

And now element web simply doesn't load. At all.

Right now the whitescreen is a bug, it should show you an incompatibility screen - https://github.com/element-hq/element-web/pull/27685 will fix that bug

I do not consider it unreasonable for users to expect Firefox ESR to work (which it has for years).

So if you're on any browser which hasn't had a feature update in over a year you expect it to work just because it did at some point in the past incidentally? Or is ESR somehow special in this belief

[obfusk]

I have some sympathy for only being able to support a limited subset of recent browsers. But this breakage is unexpected for users. And the current messaging leaves the impression that element simply does not care they now have a broken client that worked fine a few hours ago and that they cannot even export their data from.

So if you're on any browser which hasn't had a feature update in over a year you expect it to work just because it did at some point in the past incidentally? Or is ESR somehow special in this belief

Unlike "some old version of Chrome" Firefox ESR is actively supported by Mozilla and Debian etc.

[mstenta]

+1 to supporting Firefox ESR. I run Debian stable as my primary OS and use Firefox ESR.

[obfusk]

We have a supports environments thing at the top of our README for a reason.

I'm pretty sure most regular users will not have looked at the github repo, let alone seen the README. If I simply go to element.io and follow the instructions to use element web and create an account there is no mention of supported browser versions.

[obfusk]

Again, I understand not wanting to support older browsers. I get this is "policy". But users reasonably expect that actively supported browsers like Firefox ESR will work unless they are clearly told otherwise.

[t3chguy]

If I simply go to element.io and follow the instructions to use element web and create an account there is no mention of supported browser versions.

You're welcome to suggest it to the team responsible for that website https://github.com/element-hq/element.io

But users reasonably expect that actively supported browsers like Firefox ESR will work unless they are clearly told otherwise.

What about Opera? KaiOS? UC Browser? And many more. Actively maintained still, just don't meet the feature bar we need at the time we need it.

[wodny]

So if you're on any browser which hasn't had a feature update in over a year you expect it to work just because it did at some point in the past incidentally? Or is ESR somehow special in this belief

Yes, I would expect it to work fine. Applications having just stability and security fixes for a year seem pretty normal to me. I would understand if there was a critical problem in E2E and you had to drop support. But the reason for this bug seems trivial and easy to polyfill.

Debian and Firefox (ESR) are pretty important and special. Apart from Safari Firefox is the last non-chrome browser that works pretty well. They are important part of the ecosystem. Disabling them without a warning visible for a user seems pretty extreme.

[obfusk]

What about Opera? KaiOS? UC Browser? And many more. Actively maintained still, just don't meet the feature bar we need at the time we need it.

Are any of those the default browser on a major Linux distro, actively supported by Mozilla just like regular Firefox, and work fine until a few hours ago?

[t3chguy]

But the reason for this bug seems trivial and easy to polyfill.

See my earlier reply

The first driver of this was 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.

So element-web switching to Intl.Segmenter isn't the fault here, its Compound, which was done to help out a smaller project which was suffering from graphemer being so impactful on bundle size.

and work fine until a few hours ago?

Probably

[obfusk]

There are two issues here:

1. Firefox ESR is not supported; I've pointed out why I think it should be, but not supporting it is not necessarily an unreasonable decision.
2. Firefox ESR was working just fine and many users didn't realise it wasn't supported and didn't expect it to suddenly break today and to then be told it will not be fixed.

[obfusk]

and work fine until a few hours ago?

Probably

I asked for a combination of 4 things (default browser on major Linux distro, actively supported, by a major vendor (and OS), working fine). I'm not sure what saying some other browsers satisfy the last criterion is meant to prove?

[obfusk]

Look, I get the reasoning for the policy. I get supporting Firefox ESR takes more resources. What I don't get is considering it unreasonable for Debian stable users to expect element web to work for them when they could not reasonably have expected things might suddenly break and would then not be fixed.

[obfusk]

Had element web warned Firefox ESR users a few weeks ago that they were using a browser that didn't support a feature required by an upcoming version, giving them time to switch to a different browser or client instead of just randomly breaking for no apparent reason (from their PoV) today, I would still be unhappy, but not as disappointed (and likely to move away from element web and recommend others to do so as well) as I am now.

[t3chguy]

Debian stable users have access to other browsers & Element Desktop, they are not unable to use Element Web via supported means

Had element web warned Firefox ESR users a few weeks ago that they were using a browser that didn't support a feature required by an upcoming version

For a feature like that to work, you'd have to know what APIs you're going to use months in advance to warn users even if they are stepping between versions rather than hitting every single one, e.g. if someone only updates Element Web once every 2 months which is quite common for certain customers. This is a slowdown to development we can't afford as a tiny team. It'd also rely on the user not having Firefox fingerprint protections enabled, as those cause the UA to be modified.

[obfusk]

Debian stable users have access to other browsers & Element Desktop, they are not unable to use Element Web via supported means

Yes. And it's not unreasonable to tell them to use a supported means. But many could not have reasonably known that Firefox ESR is unsupported. And are now unexpectedly locked out of their existing sessions which worked fine a few hours ago.

I'm a little disappointed that Firefox ESR is not supported. But more so that I've had to drop everything to move several people to alternatives today and some of them are quite unhappy at losing access to their existing messages because they only had one session which is no longer usable.

(I will leave it at that. I don't think turning this into a long argument will help anyone.)

[t3chguy]

But many could not have reasonably known that Firefox ESR is unsupported.

I agree, and I think suggesting to the marketing team to update the element.io website with supported browsers would be sane, hence linking to the issue repo for that.

[franzcor]

Debian stable users have access to other browsers & Element Desktop, they are not unable to use Element Web via supported means

Yes. And it's not unreasonable to tell them to use a supported means. But many could not have reasonably known that Firefox ESR is unsupported. And are now unexpectedly locked out of their existing sessions which worked fine a few hours ago.

I'm a little disappointed that Firefox ESR is not supported. But more so that I've had to drop everything to move several people to alternatives today and some of them are quite unhappy at losing access to their existing messages because they only had one session which is no longer usable.

(I will leave it at that. I don't think turning this into a long argument will help anyone.)

Too late, all the people previously logged with ESR will be locked out and disappointed. This was very badly handled as element web prompted me with an update and I clicked on it thinking that it would actually not lock me out.. but I was wrong.

I think that ESR users could have been notified at least weeks ago given that It's not difficult to guess that a lot of Linux users use Debian and, obviously, a lot of them use the preinstalled browser (FF ESR). Now what? I absolutely don't want to use Element Desktop (electron) and I could use Librewolf for example, yes, but I'd rather keep using my old FF ESR. Would waiting a couple of weeks for the new release fix things "automagically" ?

[t3chguy]

I think that ESR users could have been notified at least weeks ago given that It's not difficult to guess that a lot of Linux users use Debian and, obviously, a lot of them use the preinstalled browser (FF ESR).

Sure, it's a lot harder for a group of ~3 people on the team to track all major OSes and what default browsers they ship with rather than just following the boiled down policy though.

Would waiting a couple of weeks for the new release fix things "automagically" ?

Sure, waiting for an ESR release which is at least 10 weeks overdue. Last cut was 4th July 2023 and they claim a release every 42 weeks.

[africalimedrop]

"A sovereign and secure communications platform." that 👏 doesn't 👏 support 👏 Tor 👏 Browser (or Mullvad) 🤡

[aligitor]

This was very badly handled as element web prompted me with an update and I clicked on it thinking that it would actually not lock me out.. but I was wrong.

Exactly.

I am lucky enough to have another session running on other device so I can easily move on to other matrix client. So will my community, friends and family. Having a technical issue or a debatable policy is one thing, but neglecting a group's feedback rudely is another story, it undercuts trust.

[obfusk]

But many could not have reasonably known that Firefox ESR is unsupported.

I agree, and I think suggesting to the marketing team to update the element.io website with supported browsers would be sane, hence linking to the issue repo for that.

Thanks. That would be great to prevent similar issues in the future. It's still unfortunate news for Firefox ESR users, but they will at least be informed and able to choose a supported alternative.

But this change comes too late for those Firefox ESR users that are currently locked out of their sessions, with no helpful error messages telling them what to do, some of which have now lost access to existing messages. If they are lucky, they will get a new ESR release soon and it will start working again, but how would they even know this?

As you've just agreed, these users could not have known they were using an unsupported browser. Closing this issue without providing these users any fix or at least a way to migrate their existing session to a supported client may be consistent with the support policy but is likely to make them very unhappy and lose trust.

Is there really nothing element is able and willing to do here to help these users out and prevent losing that trust in a service they thought they could rely on?

[tomac4t]

I EVEN thought there is an internet connection problem on my computer (refresh the page again and again), because of a blank page. It turn out Element doesn't support Firefox ESR. It too ridiculous for this case.

[o5k]

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

@t3chguy You are the one who authored the commit with the breaking change. I believe it is not wise for you to be arguing in this situation; it should be brought to another member of the team to decide on whether a single contributor pushing a change that breaks major usecases and releases (Debian, Tor Browser, Mullvad Browser, Waterfox, etc, etc, etc.) is wise or good for PR.

[alfem]

Firefox ESR is used, not only by Debian users, also by enterprises and governments (like mine) that need to check software updates carefully before making a big deployment to their users.

[t3chguy]

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