Properly support multiple tabs

[marcusmueller]

Steps to reproduce

1. I'm using an EMS-hosted element web 1.11.42
2. As usual, I opened a second tab to go to the element URL in order to handle a coding related manner while keeping an eye on an organizational space, and participating in a documentation-related discussion

Outcome

What did you expect?

Second tab works, as it always used to – after all, having more than one window open is a very classical power-user workflow

What happened instead?

I got a message

Element is open in another window. Click "Continue" to use Element here and disconnect the other window.

and that's more than annoying. This makes element worse to use than a significant part of the competition, which we decided against a while back.

Operating system

Linux x86_64

Browser information

FF 117.0.1

URL for webapp

chat.gnuradio.org

Application version

Element version: 1.11.42 Olm version: 3.2.14

Homeserver

https://gnuradio.ems.host

Will you send logs?

No

[marcusmueller]

This very very strong regression seems to have been introduced in matrix-org/matrix-react-sdk#11425. It is mentioned in the changelog under "Features", which is a miscategorization, on two fronts:

1. It's not a feature, but was introduced to fix a bug, and
2. it's a very strong functional regression.

The original bug that was fixed in matrix-org/matrix-react-sdk#11425 describes the taken approach as

A (somewhat hacky) option might be to lock out multiple tabs

and I'd concur; it's a very hotfix way of dealing with this. Since this requires a broadcast channel, there would be other (but potentially with downsides) ways of avoiding ratcheting races. The taken approach is understandable, but not without alternatives. This issue documents the user experience regression the taken approach entails.

[t3chguy]

It's not a feature, but was introduced to fix a bug, and

Sure it is, it guards you against the footgun of using multiple tabs which had a low risk of data corruption, with rust crypto that risk went up so the necessity for such a guard was higher.

[t3chguy]

Blocked on #2503

[bornav]

This makes it completely unusable for my use case
Reverting to v1.11.40, and freezing the automatic update till this is resolved

[marcusmueller]

@t3chguy I'm trying to understand the technical side of this: Why is this blocked on #2503? We clearly have a channel to exchange the "there's another instance running" information, why not use that for arbitrating access to the ratchet?

Is implementing @ara4n's proposed webworker really the only way out of this regression? It feels like saying "blocked on this core architectural aspects" makes it unattainable to fix this.

[t3chguy]

The channel uses a very rudimentary lock in localstorage. The Rust crypto stack needs to only run in one place due to heavy leveraging of caches, abstracting all crypto calls via serialisation in localstorage would be dreadful for performance. If you feel the Rust crypto stack should be less restrictive then please open an issue on its tracker.

[marcusmueller]

Thanks for the clarification! Much appreciated that you point me in the right directions 👍