You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Login using riot.im/app to a homeserver (say matrix.org)
Open an incognito window
Sign up in that incognito window to another homeserver, verifying your email address
Click link in email, which opens in the non-incognito window by default
State for the matrix.org server gets overwritten by the brand new state from the alternate homeserver, including e2e keys, without prompting or being able to back up.
Given the way the email flow works, it's very easy to get your configurations broken by this, and it's not obvious how to fix it (in fact, you can't if you don't have other devices with e2e keys).
Suggestions on addressing this could include either (or all) of:
Prompt before overwriting the locally stored data, especially if there are e2e keys there.
The registration window should do the email registration then ask "you to return to your original window to complete the process" - all the page did was to record that you have successfully clicked the link - rather than continue to log you into the system and override state. That would allow the incognito window to retain the information.
Store data in local storage / indexdb keyed first by "riot.im", then by the homeserver name, then by the current structure. Doing a copy to the new location on riot-web upgrade would retain all the current information. This might be the beginnings of a front page "which of your homeservers would you like to log into" UI experience, or dynamic changes between them in different windows.
The text was updated successfully, but these errors were encountered:
Fixeselement-hq/element-web#6875
Instead of overwriting what we have, we'll load the session we have and try to warn the user that they have verified an address for someone else.
Fixeselement-hq/element-web#6875
Instead of overwriting what we have, we'll load the session we have and try to warn the user that they have verified an address for someone else.
Steps to reproduce:
Given the way the email flow works, it's very easy to get your configurations broken by this, and it's not obvious how to fix it (in fact, you can't if you don't have other devices with e2e keys).
Suggestions on addressing this could include either (or all) of:
The text was updated successfully, but these errors were encountered: