This adds a basic error boundary around the entire app to catch errors during
rendering and present the user with the options on how to proceed. This is not
implemented as a modal so that it could be used selectively in portions of the
app as well, such as just the `RoomView`.
Fixes https://github.com/vector-im/riot-web/issues/11009
Part of https://github.com/vector-im/riot-web/issues/10416
This code is used by the welcome bot logic and the groups/communities section of the app. goHomeOnCancel can be removed because no matter what happens we'll end up in a room with the user (and we aren't showing a dialog anymore).
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.
This was using a separate function (in MatrixChat) that didn't
take into account whether we were supposed to be hiding the badge
for rooms so would include notifs that were hidden everywhere else.
Also make it a function & put it in RoomNotifs with all its friends.
Fixes https://github.com/vector-im/riot-web/issues/3060
On registering, we showed a spinner, and then another spinner on
top of the spinner, which led to an interesting spinner-in-box
effect.
Suppress the second type of spinner when we know we already have one.
https://github.com/matrix-org/matrix-react-sdk/pull/3101 meant we
don't get logged straight in after registering if using an email
address, but this was the point at which we made a chat with the
welcome user. Instead, set a flag in memory that we should try &
make a chat with the welcome user for that user ID if we get a
session for them.
Of course, if the user logs in on both tabs, this would mean each
would make a chat with the welcome user (although actually this
was a problem with the old code too). Check our m.direct to see if
we've started a chat with the welcome user before making one (which
also means we have to make sure the cached sync is up to date...
see comments).
When the user was on an invite page and clicked the sign up/sign in
buttons, remember that invite so we can show it again after they're
done signing up/in.
https://github.com/vector-im/riot-web/issues/9816
This is often null while the component is on its first render, and is called during that render. It is eventually populated by React, and the function re-called - we just have to be patient.
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
We look to see if there's already a user logged in and if there is,
restore that session instead of logging the user in as their new
account. We still set this 'is_registered' flag though, even though
in that case it's not a newly registered account that's being restored,
so don't set in that case.
This way the server config is consistent across login, password reset, and registration. This also brings the code into a more generic place for all 3 duplicated efforts.
