Splits UserActivity into a tristate of 'active' (last < 1s), 'passive' (lasts a
couple of mins) and neither. Read receipts are sent when 'active', read markers
are sent while 'passive'.
Also fixed a document / window mix-up on the 'blur' handler.
Also adds a unit test for UserActivity because it's quite complex now
(and changes UserActivity to make it testable by accessing the singleton
via sharedInstance() rather than exporting it directly).
Fixes https://github.com/vector-im/riot-web/issues/9023
In summary this makes RoomTiles (and RoomAvatars) do more for
themselves in terms of reacting individually to state changes in
the js-sdk.
Instead of force updating the entire room list for avatar changes
and room name changes, do this in the RoomTile and RoomAvatar
instead. This increases the number of listeners listening to the
matrix client, but allows us to properly implement a
shouldComponentUpdate for RoomTile (because the avatar, name and
notification count are now in component state)
As comment hopefully explains. This meant loading the app on an e2e
room would often be very slow as it tried to pull hundreds of events
into the timeline.
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>
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.
this is needed so that if a client which does not hide any events
sets and RM at bottom of timeline, then riot-web which hides events
sets the RM it'd set it at X-N where X is bottom and N is the amount of
hidden events at bottom of the timeline, this way now an RM will
fall through to the hidden events below a seen event.
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Sometimes it was possible for there to be a scroll event before the initial
pagination completed, which then upset the rest of the test. Just give it a few
ms to sort itself out instead.
refresh, this may need to be handled differently in the future.
Currently handling same as the new timestamp stuff
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Instead of modifying the condition for updating the RR, separate the RM and RR conditions and use an OR to decide when to set both.
Make some logs only log when DEBUG.
If the RR event has been unpaginated, the logic in `sendReadReceipt` will now fallback on the event ID of the RM which in theory is always =< RR event ID stream-wise.
We started with clientSyncState being null, which it remained
until the SYNCING event was emitted. We need to set
clientSyncState's initial value correctly.
constantTimeDispatcher lets you poke a specific react component to do something
without having to do any O(N) operations. This is useful if you have thousands
of RoomTiles in a RoomSubList and want to just tell one of them to update,
without either having to do a full comparison of this.props.list or have each
and every RoomTile subscribe to a generic event from flux or node's eventemitter
*UNTESTED*
As detailed here https://docs.google.com/document/d/1UWqdS-e1sdwkLDUY0wA4gZyIkRp-ekjsLZ8k6g_Zvso/edit, the RM state is no longer kept locally, but rather server-side. The client now uses it's locally-calculated RM to update the server and receives server updates via the per-room account data.
The sending of the RR has been bundled in to reduce traffic when sending both. In effect, whenever a RR is sent the RM is sent with it but using the new API.
This uses a js-sdk change which has set to be finalised and so might change.
The actual fix to https://github.com/vector-im/riot-web/issues/3175 is this change to `_saveScrollState`, which is to pick the trackedScrollToken based on which node is intersected by the bottom of the scroll panel. This is opposed to the previous logic that picked based on which node was the first from the bottom to be above the bottom of the viewport.
In the case where the viewport bottom does not intersect any events, the topmost event is used.
Only zero the local notification count when we actually send a
read receipt, otherwise we cause a re-render of the RoomList every
time the user moves the cursor in the window, basically.
Use an action and force an update when zeroing the number of notifications in a room. This is better than waiting for a `render` to happen at some point. This will hopefully fix https://github.com/vector-im/riot-web/issues/3257
Only claim there's nothing to display once we've failed to back
paginate, otherwise we'll show the empty message instead of the
MessagePanel and therefore never try to back-paginate.
Fix pagination issue where recent events are lost
Scrolling up a few pages followed by scrolling down to the most recent events previously caused some events to go missing. A test has been modified in conjunction with this fix to make sure that this failure mode is tested for in future. This commit should fix the issue, and the most recent events should be paginated back in.
Instead of using a window of a fixed number of events, unpaginate based on the distance of the viewport from the end of the scroll range.
The ScrollPanel uses the scrollTokens to convey to its parent (the TimelinePanel, in this case) the point to unpaginate up to. The TimelinePanel then takes a chunk of events off the front or back of `this.state.events` using `timelineWindow.unpaginate`.
Fixes https://github.com/vector-im/vector-web/issues/2020
* Actually test what we were supposed to be testing (viz, that we can paginate
back down after we hit the top of the room)
* Make the cap on the number of events we show in the timeline a configurable
property, so that we can set it in the test
* Use a smaller cap in the test, so that we have to do less paginating to hit
the cap, to make the test run quicker.
* add some more logging so that we can see how far it's got if it gets stuck.
TimelinePanel rerenders are expensive, so we want to do as few as possible. So,
when we get a new timeline event, make sure that we update the RM and add the
new event at the same time.
Adds a missing 'return' statement which meant that, even if we already had the
relevant event loaded into the DOM, we would rebuild it when the user clicked
on the "(^) Unread messages" bar.
The fix to https://github.com/vector-im/vector-web/issues/1241 introduced an
off-by-one error which meant we would show the RM before the last event in a
room. We were actually winding the RM back one if the last message wasn't sent
by us.
This fixes an issue where the RM appeared before any events which were pending
when you switched away from that room
(https://github.com/vector-im/vector-web/issues/1241).
Also, fix a buglet in the MessagePanel which meant we didn't animate the
disappearance of a RM when it stayed at the same event but became
invisible. This didn't really cause any user-visible problems (because
typically we advance the RM at the same time as it became invisible), but
confused me a bit while I was trying to debug this.
We considered the user active if there had been a user_activity event within
the last 500ms, but those events were only raised every 500ms, so it was
possible that we would be considered inactive immediately. Use
UserActivity.userCurrentlyActive() instead, which fixes this.
Also increase CURRENTLY_ACTIVE_THRESHOLD_MS to 2 seconds.
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.
Rather than telling react-gemini-scrollbar to update every time something that
changes its size happens, try out our fork of it which uses some hackery to
listen for resizes.
We need two modes of operation for ScrollPanel.scrollToToken:
For jump-to-read-marker, we want it 1/3 of the way down the screen.
For search clickthrough, and hyperlinked events, we want put the event in the
*middle* of the screen.
Fixes https://github.com/vector-im/vector-web/issues/1032
When we first hit the start of the room, we still have a pagination token, so
we hide the date separator. When we try to backpaginate again, we get an empty
result, and the pagination token is cleared.
Make sure that we update state. canBackPaginate even when there are no new
results, to handle this case.
Fixes https://github.com/vector-im/vector-web/issues/1014
