-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Element-R: lock out multiple tabs to avoid races #25157
Comments
A (somewhat hacky) option might be to lock out multiple tabs, by sending messages over a BroadcastChannel |
for now at least, we will lock out one of the tabs. Element Call have done something like this and we may be able to benefit from their implementation |
This isn't used yet, but will form part of the solution to element-hq/element-web#25157.
This isn't used yet, but will form part of the solution to element-hq/element-web#25157.
@richvdh can we add some kind of interaction to choose which tab to use Element in? For example, WhatsApp web has this: Separately, can we use Element UI components? Or does this page need to be some kind of barebones HTML/styling? If the latter, I'll whip something together copying the mobile install guide. |
the answer is (I think) "yes" to both, though we're deliberately trying to keep this feature lightweight as it's meant to be a quick alternative to "proper" multitab support. I might need help from someone like @germain-gg in using UI components in EW properly, but it's just react components like the rest of EW so should be fine. |
@nadonomy I made a loading screen that looks like this: |
* Add mechanism to check only one instance of the app is running This isn't used yet, but will form part of the solution to element-hq/element-web#25157. * disable instrumentation for SessionLock * disable coverage reporting * exclude SessionLock in sonar.properties * Revert "disable coverage reporting" This reverts commit 80c4336. * only disable session storage * use pagehide instead of visibilitychange * Add `checkSessionLockFree` * Give up waiting for a lock immediately when someone else claims * Update src/utils/SessionLock.ts
@richvdh Thanks, this is awesome! Had my config drop twice this week because I accidentally opened element in another tab. Quite frustrating to re-auth and verify again. Lovely QOL feature! |
|
@richvdh sorry for not replying earlier, I just noticed your response. My enthusiasm was genuine, although I can understand how it may have come across as sarcasm. I added my frustration for context. I can't quite remember how I landed here at the time, but the concurrent access of browser storage may have had something to do with it. The exact details are vague to me at this point. Anyhow, upon looking for a solution I stumbled upon this feature you made very recently and I was pleased to discover that opening another tab will soon be handled more gracefully. Sharing the frustration was meant to let you know that this solves a PITA for me, hence the compliment on the QOL feature. |
This sucks: not only do I open multiple tabs so that I don't have to switch between different contexts manually, this triggers even if it's open in a single tab, and I have to reload Element to fix it, with all the usual punishments for reloading. Please revert this. |
I'm afraid we can't revert this, as it is currently required to support use of the new cryptography library, which is central to our strategy for making encryption more reliable. We will track restoring multi-tab support at #26231. |
Using the Rust crypto SDK from two tabs at once will cause data corruption, due to the fact that the rust-sdk caches information in memory.
Examples of the sorts of problems that could arise:
If you send messages from both tabs to the same room, we could use the same megolm ratchet index (this is exactly the problem in Wrong message index when sending an image via Share Extension, message not decryptable in Element-Web, can break rooms when session-ID is affected! element-ios#7499)
We might create two Olm one-time-keys with the same ID, causing problems like Lost OTK, leading to "OneTime key already exists" error and later UTDs matrix-org/matrix-rust-sdk#1415.
Most disasterously of all, suppose:
In this case, each message will necessitate a megolm keyshare, which will cause the ratchet for the Olm session shared between you and Bob to be advanced. However, this will cause unrecoverable corruption to the Olm session.
In other words, you and Bob will never be able to communicate again.
The text was updated successfully, but these errors were encountered: