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
This code only kicks in if the user was ignored after an event was sent. The homeserver should prevent other events from coming in.
Signed-off-by: Travis Ralston <travpc@gmail.com>
Events are now decrypted asynchronously, so are not decrypted
at the time of the Room.timeline which is when our RoomList
got the chance to update. It needs to update once the event has
been decrypted.
Ideally we would not update the whole room list order, but this is
how all the room list re-ordering happens right now, so staying
consistent with this.
Fixes https://github.com/vector-im/riot-web/issues/5020
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
Introduce a class that consumes updates from the RoomViewStore and
announces to listeners if the active room ID is now or is no longer
the room ID they specified. Naming suggestions welcome: it's
currently called ActiveRoomObserver.
Avoids passing the selectedRoomId down from MatrixChat all the way
through the LeftPanel / RoomList / RoomSubList to the RoomTiles.
Also introduce a CallPreview class that listens directly for
RoomViewStore changes as the call preview in the left panel needs
to know when the room changes, so this allows this component to
update without having to update the entire left panel.
Adding the code code button was done by manipulating the HTML of
the event body to add a span tag, then adding the onclick handler
after the thing was mounted. Apart from splitting the code between
two places, adding the span tag was, according to Chrome's
profiler, taking up quite a lot of CPU cycles (apparently as soon
as you set the innerHTML on a div). Instead, just build the whole
lot together after the component mounts.
Emojione's regex for detecting emoji is *enourmous* and we were
running it on every display name, room name, message etc every time
those components mounted. Add a much simpler regex to rule out the
majority of strings that contain no emoji and fast-path them.
Makes room switching about 10% faster (in my tests with all the
profiling turned on).
...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.
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.
Calling just checkFill on DidMount did not initially set the
scrollTop which meant that one back pagination request is always
performed regardless. This meant we would end up rending the
first batch of events, then paginating and re-rendering again
after the pagination got another batch, causing unnecessary render
churn.
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.
If the js-sdk had a lot of history in memory for a particular room,
riot would paginate all that history into the DOM and render it
when switching to that room (before then removing it all again).
This obviously made switching to that room very slow.
This was caused by the fact that we relied on the setState that
happens in TimelinePanel after the pagination taking effect such
that ScrollPanel sees that it no longer needs to paginate, but
in some situations (as far as I can see, in electron...?) this
setState would not take effect until the pagination stopped
fulfiling requests from memory and hit the network.
Fix: don't resolve the promise returned by the pagination request
until the setState has actually happened.
Use `react-sticky` to implement sticky date separators. This will pin a date separator to the top of the timeline panel when the separator scrolls out of the top of the view.
A known issue of this is that the spinner, which is in line with event tiles in the timeline, will appear to push the stuck date separator down. In reality the first date separator after the spinner is in line with event tiles and is not stuck because the spinner forces the timeline to be scrolled slightly further down than it would be otherwise. But also, date separators in the timeline (not "stuck") have a greater height.
Ideally the date separator would be suppressed whilst back paginating, but this will cause the stuck separator to flicker on and off. This is why the suppression has been removed.
For reasons I don't fully understand, it appears that sometimes the
ReadReceiptMarker has no offsetParent. Rather than dying with an uncaught
exception when that happens (and taking out half of React as well as the /sync
handler), log a warning and suppress the animation.
- 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)
Otherwise this is incredibly annoying when developing if you don't
have a scalar that will allow you to register (ie. if you're
testing against an HS on your dev box)
And remedy weird API in the process. Autocomplete now exposes `onSelectionChange` to indicate that the user has selected another completion, rather than returning the chosen completion via onUpArrow etc.
Fixesvector-im/riot-web#4835
