Split the 'new recovery method' into two cases: one where the new
recovery method isn't trusted and you need to verify the device, and
another where it is and the client is using it (where it's more of
an FYI).
https://github.com/vector-im/riot-web/issues/8069
The "New Recovery Method" dialog would show if either the recovery method had
been changed or removed, but the dialog text didn't make much sense for the
removed case.
This adds a separate dialog customized for the removed case.
Fixes https://github.com/vector-im/riot-web/issues/8046.
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.
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.
Adds a New Recovery Method dialog which is shown when key backup fails because
of a version mismatch / version not found error.
The set up button in the dialog currently only marks a device as verified (via a
verification prompt) instead of the eventual restore and cross-sign flow, since
those pieces don't exist yet.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
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.
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.
This ends up being translated to ?server_name= in the matrix-js-sdk, although that has a bug at the time of writing. It converts `server_name: ['a', 'b']` to `?server_name=a,b` instead of `?server_name=a&server_name=b`
For reference: the `viaServers` option is routed through the 'join_room' action to RoomViewStore#_joinRoom which is passed directly to the js-sdk http-api#joinRoom function.
Next steps:
* Fix the js-sdk parsing
* Make the SDK generate matrix.to links with ?via=
Continues from Matthew's work: adds a feature flag & panel in
user settings to create a backup.
Can't restore a backup yet, nor even continue backing up to the same
backup after a refresh.
Display an error on the splash screen with the spinner if the sync
request is not working, rather than just sitting there with a spinner
as if nothing is wrong.
Fixes https://github.com/vector-im/riot-web/issues/7148
ILAG only works on HSes that allow registering without an email
address, so whenever we redirect to the ILAG flow, check what
registration flows the server supports, and if it doesn't offer one
that's ILAG-compatible, prompt the user to go through the full
registration process instead.
This doesn't change all the entry points into ILAG, I'll do that
in a separate commit.
Piwik supports sending an event value, which we can use to indicate
cardinality of UISIs to be tracked instead of tracking them individually.
This means we can track them at a lower frequency of (fairly arbitrary)
60s.
Instead of pinging Analytics once per failed decryption, add the failure
to a list of failures and after a grace period, add it to a FIFO for
tracking. On an interval, track a single failure from the FIFO.
Emit a piwik event when a decryption occurs in the category "E2E" with
the action "Decryption result" and the name either "failure" or
"success".
NB: This will cause Riot to a lot of networking when decrypting many
events. One HTTP request per decrypted event should be expected.
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
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.
The duration measured is between
- componentWillUpdate of MatrixChat and
- componentDidUpdate of MatrixChat.
This does not account for *all* changes to the view that occur
when a room switch happens, for example. But it does at least
capture the difference between switching to a "big" room and
switching to a small test room.
This was for when the new and old versions were available
concurrently on /develop and /app.
The various migration steps are still logged to the console in
js-sdk.
Don't pop up the dialog as soon as we can't send a message.
Also removes dispatches used to keep the RoomStatusBar up to date.
We can get the same events straight from the js-sdk via the
pending events event.
...on room switch. We were setting most of the state in viewRoom,
but getting the current room ID from the RoomViewStore, but this
meant we did one setState from the RoomViewStore updating,
re-rendered and then setState again in viewRoom causing another
render. This just sets the room ID in viewRoom.
- this should fix a race where if the 'hangup' arrives hard on the tail of the
Call.incoming, we don't ignore it.
(We still have a problem in that we blip the hangup tone and UI, but that is
arguably a separate problem)
the RightPanel will be mounted once we're done doing the first sync, so wait until then and then dispatch a view_user. This is not very nice but it's what we do for view_room.
With the fallback of existing behaviour, which is UserView (no middle panel and no avatar, display name).
To improve, MemberInfo should probably track the current roomId and userId and then update the view asynchronously by re-fetching the member object when either roomId or userId change.
Also, it should be hitting the profile API to get the user's avatar if a room hasn't been specified.
This is mostly with the intent of making the login tests more reliable, but it
seems generally worthwhile:
* keep screenAfterLogin in the object props rather than `state` so that we can
clear it without triggering a rerender
* also move our record of the window width to the object props, and call
`handleResize` from componentWillMount rather than componentDidMount so that
we don't trigger a rerender by updating `state.width`
* Remove update of unused `loading` state
* don't just log errors without any context as to where they came from or what
they mean
* avoid the use of '%s' and multi-argument console.log because it looks awful
under karma.
Fixes riot-web#4334
When we do a token login, don't carry on with the normal app startup
(transitioning to the loggedIn state etc) - instead tell the app about the
successful login and wait for it to redirect.
Replace onLoadCompleted with onTokenLoginCompleted so that the app can see what
it's supposed to be doing.
MatrixChat is essentially a glorified state machine, with its states partially
determined by the loading, loggedIn and loggingIn state flags. If we actually
make each of the states implied by those flags an explicit 'view', then
everything gets much clearer.
'screen' is overloaded, as it us used for the parameter of `showScreen` (and,
by implication, `state.screenAfterLogin`). Attempt to clear up the confusion by
replacing 'screen' with 'view' and using some constants for the potential
values.
This should be a no-op!
This fixes an unintuitive behaviour where, if you follow a link to
riot.im/app/#/login, we take you to the login page, but not before we've
registered a guest account (or restarted the MatrixClient with the stored
creds).
This actually ends up simplifying some of the startup dance, as we special-case
the registration flows earlier on.
Fix for https://github.com/vector-im/riot-web/issues/4224
Due to the way `MatrixChat` does a state update when the `view_room` dispatch fires and a second update when `RoomViewStore` sends an update, the current event ID and room ID were becoming out of sync. The solution devised was to have the event ID managed by the `RoomViewStore` itself and do any defaulting there (for when we revisit a room that we saved scroll state for previously).
This required a few changes:
- The addition of `update_scroll_state` in `RoomViewStore` allows the `RoomView` to save scroll state for a room before swapping to another one. Previously the caching of scroll state was done in `RoomView`.
- The `view_room` dispatch now accepts an `event_id`, which dictates which event is supposed to be scrolled to in the `MessagePanel` when a new room is viewed. It also accepts `event_offset`, but currently, this isn't passed in by a dispatch in the app, but it is clobbered when loading the default position when an `event_id` isn't specified. Finally, `highlighted` was added to distinguish whether the initial event being scrolled to is also highlighted. This flag is also used by `viewRoom` in `MatrixChat` in order to decide whether to `notifyNewScreen` with the specified `event_id`.
