If guest access was enabled, clicking the login link on the 'registration
completed' page would just load the guest account you had before registering.
Fixes https://github.com/vector-im/riot-web/issues/10482
Fixes https://github.com/vector-im/riot-web/issues/10235
CSS and copy are left as an exercise for a later iteration.
Login page handling is left for https://github.com/vector-im/riot-web/issues/10236
This implementation reuses as much of the Lifecycle flow as it can without causing problems. Most importantly, it requires https://github.com/matrix-org/matrix-js-sdk/pull/975 to be able to detect a soft logout and react to it. When it comes time to starting/stopping the Lifecycle, additional parameters are provided so that the auxiliary services can (re)start themselves without the client starting to sync.
https://github.com/matrix-org/matrix-react-sdk/pull/2826 checked
that we had data in the crypto store if the had credentials in
localStorage. However, SSO stores creds in localStorage and then
redirects the browser to remove the loginToken parameter from the
URL without starting crypto, so after the redirect, we see creds
in localStorage but no crypto data, and error.
Fix by marking when we've successfully initialised crypto and only
erroring if that flag is set.
Fixes https://github.com/vector-im/riot-web/issues/9695
Regressed in https://github.com/matrix-org/matrix-react-sdk/pull/2768
where we check for an existing stored account first and restore that
instead if it exist, telling the user. We usually make a guest account
when the user first hits the page though, so this just restored this
guest account.
Don't restore the account if it's just a guest account (which, as per
comment, is not perfect, but is definitely better than the current
behaviour).
Fixes https://github.com/vector-im/riot-web/issues/9581
If we have account data in local storage but nothing in the crypto store, it
generally means the browser has evicted IndexedDB out from under us. This adds a
modal to explain the situation and offer to completely clear storage to get
things back to normal.
Fixes https://github.com/vector-im/riot-web/issues/9109
This adds a storage consistency check just before creating a client on login.
Each data store we use is checked for data and any problems are logged to the
console.
Fixes https://github.com/vector-im/riot-web/issues/9271
Splits UserActivity into a tristate of 'active' (last < 1s), 'passive' (lasts a
couple of mins) and neither. Read receipts are sent when 'active', read markers
are sent while 'passive'.
Also fixed a document / window mix-up on the 'blur' handler.
Also adds a unit test for UserActivity because it's quite complex now
(and changes UserActivity to make it testable by accessing the singleton
via sharedInstance() rather than exporting it directly).
Fixes https://github.com/vector-im/riot-web/issues/9023
Fixes https://github.com/vector-im/riot-web/issues/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.
When I was talking to Matthew about this the other day, we couldn't think of a
good reason why we should preserve the HS URL at logout. It introduces the
problem that, if a client is redirected after login as per MSC1730, and then
you log out, you'll then get a login screen for the wrong server.
So basically there's no reason to have an mx_hs_url/mx_is_url without an access
token, and we can remove the stuff which preserves it, and the stuff that
attempts to restore it.
ActiveWidgetStore is now reponsible for removing the current
persistent widget from the store if it's been removed from whatever
room it was in. As per comment, this leaves us with the store updating
itself in this case but in all other cases, views call setters on the
store to update its state. We should make it so the store keeps itself
up to date and views aren't responsible for keeping the store up to date.
The store now emits events so it can notify PersistentApp when it changes.
Fixes https://github.com/vector-im/riot-web/issues/7076
The user might (probably does) have a session even if we haven't actually tried
to load it yet, so wrap the whole loadSession code in the error handler we were
using for restoring sessions so we gracefully handle exceptions that happen
before trying to restore sessions too.
Remove the catch in MatrixChat that sent you to the login screen. This is
never the right way to handle an error condition: we should only display the
login screen if we successfully determined that the user has no session, or
they explicitly chose to blow their sessions away.
Fix a number of failures that meant the excellent error handling
we had for failing to restore a session didn't work.
1. .catch on the promise rather than try/catch: it's async
2. Explicit cancel method in SessionRestoreErrorDialog that invokes
onFinished with `false` because even with the catch fixed, this
was getting the event as its first arg which is truthy, so
clicking cancel still deleted your data.
3. DialogButtons: Don't pass onCancel straight into the button event
handler as this leaks the MouseEvent through as an argument.
Nothing is using it and it exacerbates failures like this
because there are surprise arguments.
Fixes https://github.com/vector-im/riot-web/issues/6616
