and also things like the unsent message error and encryption
warning.
Stuff that we need to do at room view mount time had got moved into
a clause of the if statement in onHaveRoom and so wasn't being
executed.
Fixes https://github.com/vector-im/riot-web/issues/4327
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!
If we successfully join, display a spinner until the js-sdk indicates (via room membership event or room event) that we can start using the room normally. A room event indicates we have never seen that room which means we need to use the new room object to clobber state.room. This is to make sure we replace the room that is set up for peeking with the room that can be used normally. For historical rooms, this isn't a problem.
This is a workaround for the fact that when peeking, the js-sdk calls onRoom, which is difficult to handle from the clients perspective because onRoom should only be called for rooms that you've never seen before. But if you peek a room that you've joined and left and get an onRoom, you run into trouble. You also can't just always use onRoomMembership because this won't be triggered for the first time you see the room. So we end up using a combination of both.
See https://github.com/matrix-org/matrix-js-sdk/issues/464 for discussion on improving this
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.
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.
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`.
This reverts commit c3d37c1ff9.
This commit was introducing a bug where no rooms would be shown if
you want straight to /#/login and logged in (because this causes
a guest session to be created but the indexeddb store not to be
cleared, so the new login picks up the stale indexedb sync data.
Before, we were relying on the fact that `ready` would still have
been false from before. This was not the case, for example, if we
naviagted straight to /#/login (which causes a guest session to be
set up and the sync for that completes after we navigate to the
login screen).
We should always mark ourselves as not-ready after login since we
will always have to wait for the sync.
In order to get ILAG internationalised
Conflicts:
src/components/structures/LoggedInView.js
src/components/structures/MatrixChat.js
src/components/views/dialogs/ChatCreateOrReuseDialog.js
src/components/views/dialogs/SetDisplayNameDialog.js
src/createRoom.js
src/i18n/strings/en_EN.json
This reverts commit c3d37c1ff9.
This commit was introducing a bug where no rooms would be shown if
you want straight to /#/login and logged in (because this causes
a guest session to be created but the indexeddb store not to be
cleared, so the new login picks up the stale indexedb sync data.