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.
