Use the new register-specific request token endpoint (https://github.com/matrix-org/matrix-js-sdk/pull/147) and catch the error that it gives if the email is already in use. Also add initial values to the registration form so we can reload it after the error without all the values disappearing, and split out the guest username parameter which was previously called defaultUsername.
1) custom HS/IS urls are now persisted in HTML5 local storage. As a result, all the login components now distinguish between default HS/IS URLs and custom specified ones again. (
2) custom HS/IS urls are synchronised between the instances of ServerConfig found in the Login, Registration and Forgot Password screens.
3) username are persisted over changing homeserver (but not password, to stop accidentally leaking passwords to the wrong server)
4) correctly interpret a blank URL field as meaning the placeholder text
5) when toggling custom URLs on and off, remember what the custom values were, and use the default URLs if custom mode is not engaged
also, guest access now upholds custom HS/IS URLs found in local storage rather than being limited to the server config ()
also adds assorted comments and improved console debug and a few minor cosmetic changes to the login components.
this commit sponsored by VS27...
This is preferable to doing the way other QPs are passed (secret, etc) because
the link in the email wants to look like "#/room/<room_id_or_alias>" for guest
read-access (only bouncing you to /login if that room is not readable by guests).
This is hard to do in the current arch because we don't preserve QPs on /room
paths, and we do conditional executions depending on if it is a room ID or
alias. Rather than threading through the email in each section and creating
a fragile mess, just pass the *starting* set of query parameters through to
MatrixChat which can then do the Right Thing when the time comes.
David Baker