* 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
If the event corresponding to the read-up-to mark hasn't been loaded into the
timeline window, we can't simply scroll to it. Instead, reload the timeline,
centered on the RM event.
Fixes https://github.com/vector-im/vector-web/issues/1055
This reverts commit a7c75b1315, reversing
changes made to b66ca74ede.
This is causing breakage in the messagepanel screen resize after video call and
room settings
We had a problem handling gappy syncs: resetting the timeline would trigger a
pagination request (which would return no results, because there are no events
at this point); this would make the pagination requests which are spawned when
we process the events in the sync get ignored - with the result that we get a
blank window.
The fix is to avoid the ScrollPanel when we are processing new live events and
tell the TimelineWindow to paginate itself directly.
After a resume from sleep, we don't want to start paginating through the whole
timeline. If we were in 'stuckAtBottom' mode before, treat a gappy sync
similarly to how we handle the 'scroll to bottom' knob, which is to reload the
timelinewindow starting from scratch.
Fixes https://github.com/vector-im/vector-web/issues/932, and will probably
also fix https://github.com/vector-im/vector-web/issues/943, though I haven't
tested it yet.
