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.
Known issues at this point:
* The room-level setting accepts the current user's default, which is wrong
* The checkboxes on RoomSettings are not independent
* The checkboxes in RoomSettings need some layout fixes
Signed-off-by: Travis Ralston <travpc@gmail.com>
After accepting a 3pid invite.
Rather than clear the joining flag when the join request completes,
leave it so the RoomView can see that we're expecting the user to
be joined in the various stages that might go through (waiting for
join request, waiting for room object, waiting for 'joined' member
event). The problem in this case was that we had to wait a bit for
the last one, and there was no bit of state to represent it.
This hopefully also makes the logic somewhat simpler.
Fixes https://github.com/vector-im/riot-web/issues/5041
Ignore the update that comes in from the RoomViewStore when the
current room changes or we save our scoll state against the new
room rather than the old one.
Fixes https://github.com/vector-im/riot-web/issues/5010
onHaveRoom sets some more state (among other things) so putting it
in the setState callback so it could observe the new state caused
us to have to re-render again unnecessarily. Just give it the new
state as a parameter.
to keep the place we're scrolled to in rooms. This mainly eleimates
the extra, superfluous onRoomViewStoreUpdate callback that
happened when the previous room saved back its scroll state.
Moving the scroll state to a separate store means we can have this
not emit events because nothing needs to know when the scroll state
changes.
* Implement new widget API
This allows clients to see who provisioned which widgets.
* Update to make state_key the wid
* Update to latest API
* Only show widgets which have required fields
* Don't constantly show apps dialog
* Fix example to include data key
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
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
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`.
