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 👍

[ChristianMayer]

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.

It's not a feature. It's a huge UX regression.

That it was introduced to fix something deemed even worse (and probably is even worse) doesn't stop it from being an UX regression. Preventing users from using multiple tabs is a broken UX design.

[xarinatan]

I ran into this issue today somehow, but without having multiple tabs open. No amount of refreshing and restarting Firefox would fix the issue, eventually I cleared the cookies/site data for that domain and everything was fine and dandy again.

[bornav]

@xarinatan did you update the element client, same happened to me when I updated the client

[xarinatan]

@bornav I'm not entirely sure what triggered it, my laptop ran out of power (so the browsing session was force-closed while on standby) so that could be a reason, I have a system that automatically updates the Matrix/Element containers to whatever's the latest tag on docker's registry so it could've been updated in that time, too.

Once it was triggered there was no way to resolve it without clearing the cookies/session storage for Element though. I restarted Firefox, ctrl+reloaded the page as well as just re-opening the page and browsing back to the main domain, to no avail, until I reset the aforementioned data.

[xarinatan]

I'm having the same issue again, different machine this time, again the only solution is to completely reset the cookies/local site data for Matrix.. I doubt I'm the only one who runs into this if it happens this often.

It's seemingly onset by laptops having ran out of power while in standby, I bet there's a very simple locking mechanism that just marks the session as locked when Element is initialized, but that means if the browser is ended incorrectly it'll cause Element to think its session is unavailable when it's not.

[marcusmueller]

@xarinatan you're describing a separate issue, as far as I understand it, namely that single-tab-ensurance mechanism has a bug. So, please fill in a separate issue. Help the maintainers – keep separate issues separate, a bug tracker is not a discussion forum. Thank you!

[ctrlbrk42]

@Reactongraph an unrelated issue is not a support forum. Rust crypto is no longer disableable as per its removal from https://github.com/element-hq/element-web/blob/develop/docs/labs.md#use-the-rust-cryptography-implementation-feature_rust_crypto-in-development

Hi,

Is this thread still current -- broken multiple tabs (due to crypto module/E2EE)?

I've been working to try and enable multiple tab support as well, and I don't need E2EE. So this news of the module being removed was new to me.

I'm trying to understand why the issue still exists if the module was removed?

[t3chguy]

@ctrlbrk42 the module was not removed, the labs flag for it has, it is now the only supported module. Thus as it cannot be disabled, you cannot simply skip the legacy variant from the build as was previously supported.

[ctrlbrk42]

@ctrlbrk42 the module was not removed, the labs flag for it has, it is now the only supported module.

Ok thank you. So does that mean there is no longer any possibility of multiple tab support? This issue should be closed as "won't fix"? Or is there still a plan to solve it?

My entire project requires no E2EE and also requires multi-tab, so I'm doing my best to understand the current state.

I get this isn't a support forum but I've spent weeks trying to solve this on my own. So I guess I'm asking for a little pity lol 😂.

I would offer a bounty or whatever it takes to solve this issue.

Thank you for taking time to respond.

[t3chguy]

Or is there still a plan to solve it?

That's up to the crypto team, if they had thought its a wont-fix I'd have expected they would have closed this by now

[richvdh]

Speaking from the crypto team: we hope to fix it one day, but it is not currently a priority.

My entire project requires no E2EE and also requires multi-tab, so I'm doing my best to understand the current state.

Possibly you could build a fork of Element that disables E2EE support, and also disables the multi-tab check; but bear in mind that's not a configuration we support or test, so it's hard to say what brokenness you would encounter.

[richvdh]

I discussed potential approaches to fixing this with the Rust team recently. In particular, we considered whether the best approach was to shift E2EE processing into a shared worker (per #2503), or whether we could make use of a cross-process lock (probably drawing inspiration from that used by Element X iOS (see https://docs.rs/matrix-sdk-common/latest/matrix_sdk_common/store_locks/struct.CrossProcessStoreLock.html, etc)).

The conclusion was that the cross-process lock would not perform well where there are multiple processes all competing for access to the crypto store; in particular, a context-switch is very invasive because each process essentially has to flush and reload its entire cached state. This is ok in Element X iOS, where a switch between the NSE process and the main process is relatively rare, but in an environment like web where you could easily have multiple active tabs on screen at once, it would likely be prohibitive.

The plan here is still, therefore, #2503. However, it's still not our most pressing priority.

[marcusmueller]

@richvdh thanks for the update :) Feels pretty sad that "we should move cryptography out of the main thread" identified in 2016 is tech debt that after 8 years still is low priority, considering it is cause for a massive usability regression.

Currently, I'm having two times the firefox + Element Web memory footprint, because I need to run two independent firefox profiles to even be able to keep two conversations in view at the same time, and do better cross-communication than "copy, change room, paste, remark, read, copy, change room…". Slack works better than that!

[marcusmueller]

@richvdh thank you for the update, honestly and really appreciated you discuss this :)

As a reminder on my position on this: although tagged "T-Enhancement", this is a feature regression from a user's point of view (no matter what necessitates it). It does seem to me you (and many others) generally did spend a significant amount of effort in identifying, accounting for, and finding potential solutions to, this issue, with an 8 year old @ara4n tech debt issue being pinpointed as the underlying problem; and: thank you!

Now, telling me "Ok, this is tech debt, but we're not foreseeably going to tackle it" is a message, which, in all honesty, I'm struggling to decode:

I'm not sure you're telling me to use another client, as this one isn't going to be fixed. If so, please do that – I can take it – and close the issue as wontfix. If you're not telling me that, I don't understand the categorization as enhancement rather than bug.

[richvdh]

I'm not seeing anyone refer to either this issue or #2503 as "tech debt"?

As for prioritisation and labelling of this issue: sure, you can argue it's a regression, but I don't think it hugely matters in practice whether it's labelled as "T-Enhancement" or "T-Defect". My answer is the same: we'd love to fix this, but given everything else we have on our agenda (element-hq/element-meta#245, improved security, dehydrated devices), I can't promise you that we're going to get to it any time soon.

[marcusmueller]

Again, thanks for keeping me informed!

I'm not seeing anyone refer to either this issue or #2503 as "tech debt"?

as @ara4n writes:

We shouldn't be locking up the UI when encrypting/decrypting E2E; shouldn't this be in a bg worker?

certainly sounds like "this is something we shouldn't be doing, but are doing for the time being", to me. Isn't that what tech debt is? Slightly questionable to questionable foundations atop of which things are built that lead to issues (like this one!) later on?

Anyways, don't think the two of us should be arguing over semantics, there, that only eats your time to no benefit to anyone :)

we'd love to fix this, but given everything else we have on our agenda (element-hq/element-meta#245, improved security, dehydrated devices), I can't promise you that we're going to get to it any time soon.

Understood. I'll adjust my expectations accordingly.