...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`.
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.
This is a URL that can be used to start a chat with a user.
- If the user is a guest, setMxId dialog will appear before anything and a defered action will cause `ChatCreateOrReuseDialog` to appear once they've logged in.
- If the user is registered, they will not see the setMxId dialog.
fixes https://github.com/vector-im/riot-web/issues/4034
but with this at least clicking on a text input will not make you
be thrown into composer instead
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
These must now make a dispatch to RoomViewStore instead of calling `viewRoom` directly on MatrixChat. This will call both `viewRoom` of MatrixChat _and_ the logic in RVS so there is some redundancy here. It'd be best to move as much as possible of viewRoom out to the RVS itself.
But for now, this fixes a bug that occures when leaving (the viewed room would not change).
This changes the default behaviour of displaying the room directory to instead displaying the default homepage. If specified, the config "welcomePageUrl" can be used to override the default '/home.html'.
This allows for a truely flux-y way of storing the currently viewed room, making some callbacks (like onRoomIdResolved) redundant and making sure that the currently viewed room (ID) is only stored in one place as opposed to the previous many places.
This was required for the `join_room` action which can be dispatched to join the currently viewed room.
Another change was to introduce `LifeCycleStore` which is a start at encorporating state related to the lifecycle of the app into a flux store. Currently it only contains an action which will be dispatched when the sync state has become PREPARED. This was necessary to do a deferred dispatch of `join_room` following the registration of a PWLU (PassWord-Less User).
The following actions are introduced:
- RoomViewStore:
- `view_room`: dispatch to change the currently viewed room ID
- `join_room`: dispatch to join the currently viewed room
- LifecycleStore:
- `do_after_sync_prepared`: dispatch to store an action which will be dispatched when `sync_state` is dispatched with `state = 'PREPARED'`
- MatrixChat:
- `sync_state`: dispatched when the sync state changes. Ideally there'd be a SyncStateStore that emitted an `update` upon receiving this, but for now the `LifecycleStore` will listen for `sync_state` directly.
This will shift focus to the welcome user DM.
We probably don't want to do this for teams, but I shall leave that for another PR that fixes teams WRT to new-guest-access.
This will shift focus to the welcome user DM.
We probably don't want to do this for teams, but I shall leave that for another PR that fixes teams WRT to new-guest-access.
This wraps session-related state into a basic flux store. The localStorage item 'mx_pass' is the only thing managed by this store for now but it could easily be extended to track other items (like the teamToken which is passed around through props a lot)
- Replaces SetDisplayNameDialog with SetMxIdDialog. This new dialog will use InteractiveAuth to authenticate a user with their chosen mxid.
De-scoped:
- style tweaks for the InteractiveAuth in the dialog (capcha) and error message.
- checking for mxid availability
This was an issue because guests do not log in with a teamToken, it is implicitly set by MatrixChat when it mounts. The fix is to view_home_page when a login occurs and MatrixChat has this._teamToken set.
- Create a promise that will serve as a lock to be blocked on by things that need to wait for the first sync before accessing state.
- Use this promise to block `view_room` calls until a sync has occured instead of just dropping them silently if the sync hasn't happened yet.
- Store the current room ID in a localStorage item `mx_last_room_id` when `view_room` fires. This persists the last viewed room ID so that it can be restored on refresh, browser quit. This replaces the previous logic which set the room following a sync based on the most recent unread room.
MatrixChat was trying to display an error if the session failed to
restore, but it was never actually being shown because it was just
set as a member variable and therefore never actually caused
a re-render for the error to be displayed. Almost all errors are
caught by _restoreFromLocalStorage which displays the fancy dialog
if your session can't be restored, so I'm not convinced this ever
even tried to do anything anyway. Remove it.
Specifically:
```
JS 2.1.1 (Linux 0.0.0) joining a room over federation should not get stuck at a spinner FAILED
Did not find exactly one match (found: 0) for componentType:function (props, context, updater) {
```
actually meant that the room directory wasn't displayed - probably because the dispatch `view_room_directory` ended up on another tick of the event loop, meaning that the directory wasn't displayedi. The fix attempted in ths commit is to use `this._setPage` instead to view the directory. This uses `setState` to set the screen to the directory, so I'm not entirely convinced this will solve the problem (as `setState` may also end up doing things on another tick.
and
```
JS 2.1.1 (Linux 0.0.0) loading: MatrixClient rehydrated from stored credentials: shows a room view if we followed a room link FAILED
MatrixChat still not ready after 5 tries
awaitRoomView@/home/travis/build/vector-im/riot-web/test/all-tests.js:201363:90
```
was happening probably because in the handler for the `sync` event in `MatrixChat` (around line 840), there was one case in which the `ready` state may not be true (causing all 5 attempts to fail), and this case relied on `starting_room_alias_payload`. This `starting_room_alias_payload` is now redundant because of `initialScreenAfterLogin`, which was added recently.
To prevent the login screen from flashing when refreshing the app, use some state to indicate that a login is in progress, and OR that with the existing `loading` boolean to show the `<Spinner>` instead of the default `<Login>`.
This might be too invasive, and a default spinner may be better.
_onLoadCompleted happens straight away because Lifecycle finishes loading the session instantly when registration parameters (client_secret etc.) are set.
This follows from a small amount of refactoring done when RTS was introduced. Instead of setting the screen after sync, do it only after login.
This requires as-yet-to-be-PRd riot-web changes.
This includes:
- initialScreenAfterLogin, which can be used to set the screen after login, and represents the screen that would be viewed if the window.location at the time of initialising Riot were routed.
- guestCreds are now part of state, because otherwise they don't cause the login/registration views to update when set.
- instead of worrying about races and using this._setPage, use a dispatch.
Use the on_logged_in dispatch instead. Call setPage in one place, _onLoggedIn, when deciding which page to view on login. Change some require to import, var to const. Remove onTeamMemberRegistered and just use a nullable argument to onRegistered
For example, if someone ends up on /home somehow, just redirect to the directory instead of displaying a very awkward "File not found" plain text in the home page iFrame.
Use the first path segment to key off config.teamTokenMap, which contains a mapping to teamTokens. The client then behaves as before, keeping the path in the address bar constant with no redirects required.
Now that the RTS contains config for teams, use GET /teams to get that information so that users will see be able to register as a team (but not yet auto-join rooms, be sent to welcome page or be tracked as a referral).
* Implement simple team-based registration
Config required goes in the `teams` top-level property in config.json. This consists of an array of team objects:
```json
{
"name": "University of Bath",
"emailSuffix": "bath.ac.uk"
}
```
These can be selected on registration and require a user to have a certain email address in order to register as part of a team. This is for vector-im/riot-web#2940. The next step would be sending users with emails matching the emailSuffix of a team to the correct welcome page as in vector-im/riot-web#2430.
* Render attachments inside iframes.
* Fix up the image and video views
* Fix m.audio
* Comments, and only use the cross domain renderer if the attachment is encrypted
* Fix whitespace
* Don't decrypt file attachments immediately
* Use https://usercontent.riot.im/v1.html by default
* typos
* Put the config in the React context.
Use it in MFileBody to configure the cross origin renderer URL.
* Call it appConfig in the context
* Return the promises so they don't get dropped
The idea here is to make a layer which sits around for as long as we have a
valid MatrixClient. Also it makes a plausible split for the render of
MatrixChat, even if they are much too tightly bound for now.
Don't use replaceState in MatrixClient: there's lots of stuff in
MatrixClient's state now (including the app version) so replacing
the entire state doesn't really make sense (and also blows away
all of the nice defaults we set in getInitialState). Instead,
setState of the things we actually care about wherever we used
replaceState.
Also add a couple of state variables to getInitialState that were
missing.
Fixes https://github.com/vector-im/vector-web/issues/2322
Get rid of MatrixClientPeg.replaceUsingUrls, and instead create local,
temporary MatrixClients for the unauthed steps; we therefore only use
MatrixClientPeg for logged-in clients.
move the logic for handling login tokens into Lifecycle.loadSession
This means it needs access to the (real) query parmeters, so it depends on
corresponding changes in vector-web.
Make sure that we use the homeserver from localstorage for guest regsistration,
in preference to the default.
Also rename the parameters for loadSession
Take some of the magic out of MatrixChat.componentDidMount() into a new
component.
Also delete the MatrixChat test. It wasn't really doing much, is broken by the
change, and I am replacing it with (better) app-level tests in the vector
project.
when login completes, we replace the whole state, which means we unset
collapse_lhs, which then leads to complaints from the RoomList.
I think the 'default view' for MatrixChat ought to be factored out to another
component, which could manage collapse_lhs properly; but for now, hack around
it.
Also try to refactor some of the login/logout code out of MatrixChat and into a separate Lifecycle.js. This still isn't great, but it at least gets some code out of MatrixClient.
Plus a number of other tidyups:
* Fix /join to dispatch a view_room for the room alias
with the additional auto_join parameter
* Make RoomView automatically join the room if the auto_join
parameter is true and the user isn't already in it
* Tidy up RoomView's peeking code, also fixing
https://github.com/vector-im/vector-web/issues/1220
in react-sdk (although it still requires a synapse change
to actually fix, but react-sdk does 'the right thing').
* Remove duplication of usage text from /join command
* Amalgamate MatrixChat::_viewRoom's many, many parameters
into an object and sort out case consistency a little.
Add a callback to RoomView that it can give the room ID to once it's resolved it, since this lookup is now the responsibility of the roomview and only the roomview. The view_room action now has either an alias or an ID, not both. Also fix RoomView to load the room properly and not try to peek when it shouldn't.
Sorts out more of the room joining mess. currentRoom which held the room ID is now more appropriately called currentRoomId. RoomView will now take a roomID or alias as before but will now look up the room ID as required if given the alias. Also, now look up the alias every time you click on it so it's never stale, rather than looking in your current rooms for a room that thinks it has that ID.
This hopefully fixes an issue where joining a federated room via the directory
would get stuck at a spinner of doom, due to us not recognising the room in
question when it came down the /sync. We now catch the room id in the response
from the /join, and use it to match up the room in onRoom.
props.roomAlias, props.roomId, and state.room.roomId were somewhat confusing,
so I've tried to rationalise them:
* props.roomAlias (named thus to stop you assuming it's a room id) is the
thing that the parent component uses to identify the room of interest, and
can be either an ID or an alias (ie, it replaces props.roomId and
props.roomAlias)
* Everything that needs a room ID now has to get it from state.room.roomId.
The MatrixClient never gets unmounted in the real app, but I've been working on
some tests which would rather like to be able to create and destroy MatrixChats
and not have the clients hang around forever.
Update react-sdk to use `pendingEventOrdering`==`detached` instead of
`end`. Look for pending events in the pendingEvent list, and use
MatrixClient.cancelPendingEvent to, uh, cancel pending events.
Pass the invited email through to RoomPreviewBar, display it in a temporary way currently.
Remove a condition from RoomView render that appears to be functionally identical to the previous.
