All of the anchors were pointed at `#` which, when clicked, would trigger a hash change in the browser. This change races the change made by the screen handling where the screen handling ends up losing. Because the hash is then tracked as empty rather than `#/login` (for example), the state machine considers future changes as no-ops and doesn't do anything with them.
By using `preventDefault` and `stopPropagation` on the anchor click events, we prevent the browser from automatically going to an empty hash, which then means the screen handling isn't racing the browser, and the hash change state machine doesn't no-op.
After applying that fix, going between pages worked great unless you were going from /login to /home. This is because the MatrixChat state machine was now out of sync (a `view` of `LOGIN` but a `page` of `HomePage` - an invalid state). All we have to do here is ensure the right view is used when navigating to the homepage.
Fixes https://github.com/vector-im/riot-web/issues/4061
Note: the concerns in 4061 about logging out upon entering the view appear to have been solved. Navigating to the login page doesn't obliterate your session, at least in my testing.
They are now independent of each other. If both are specified in the config, the user will see an error and be prevented from logging in. The expected behaviour is that when a default server name is given, we do a .well-known lookup to find the default homeserver (and block the UI while we do this to prevent it from using matrix.org while we go out and find more information). If the config specifies just a default homeserver URL however, we don't do anything special.
Fixes https://github.com/vector-im/riot-web/issues/7724
The `default_server_name` from the config gets displayed in the "Login with my [server] matrix ID" dropdown when the default server is being used. At this point, we also discourage the use of the `default_hs_url` and `default_is_url` options because we do an implicit .well-known lookup to configure the client based on the `default_server_name`. If the URLs are still present in the config, we'll honour them and won't do a .well-known lookup when the URLs are mixed with the new server_name option. Users will be warned if the `default_server_name` does not match the `default_hs_url` if both are supplied. Users are additionally prevented from logging in, registering, and resetting their password if the implicit .well-known check fails - this is to prevent people from doing actions against the wrong homeserver.
This relies on https://github.com/matrix-org/matrix-js-sdk/pull/799 as we now do auto discovery in two places. Instead of bringing the .well-known out to its own utility class in the react-sdk, we might as well drag it out to the js-sdk.
Update the Login component so that if it sees an unrecognised login flow, it
just ignores it and uses another one, so that riot can still be used with
homeservers supporting custom login types.
as it's much nicer in the CSS to wrap the LoginBox as needed rather than have separate header & footer divs floating above and below it which need to be correctly vertically centered
This makes all the various hits done by login report the same
useful error messages and gets rid of the broken ones like printing
the http status code even if it was undefined. Also add text for
the case of overzealous browser extensions because lots of people
get bitten by it.
