as we're approaching from the last node, if we're scrolled up,
the first node we encounter would be below the bottom of the viewport
change the logic to stop at the first node that has its top
above the viewport bottom.
When completely scrolled up, this was causing nodes way below
the viewport to be selected as the reference for the pixelOffset,
and when pagination came in, it would immediately try to apply
the big negative pixelOffset, scrolling to a negative scrollTop,
thus going to the top again, and triggering another pagination,
entering in an infinite pagination loop until you scrolled down.
this is not nearly as smooth as using ResizeObserver, as the
callback rate is a lot lower, but seems to be quite a bit better
than what we have right now, without the 7% cpu hog that
the requestAnimationFrame polling fallback has.
before we would clear it as soon as you were 1px away from
the bottom of the timeline, which would still create jumping as
the whitespace would around 36px. To play it safe, we only clear it
after moving 200px from the bottom.
Also include "local echo" scroll events, caused by setting scrollTop
- Remove featured users/rooms
- Add "Rooms" section to show all rooms in the group in a room-directory-esque list. This has a "+" button in "edit" mode.
- Make the group view body scrollable
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.
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.
- Instead of using one attribute, use one that might just contain one token
- Use the first token when tracking a child
- Mandate that no commas can be in individual tokens
This adds the `data-contained-scroll-tokens` API to elements in `ScrollPanel` which allows arbitrary containers of elements with scroll tokens to declare their contained scroll tokens. When jumping to a scroll token inside a container, the `ScrollPanel` will act as if it is scrolling to the container itself, not the child.
MELS has been modified such that it exposes the scroll tokens of all events that exist within it.This means "Jump to unread message" will work if the unread event is within a MELS (which is any member event, because even individual member events surrounded by other events are put inside a MELS).
Making sure that a node is intersected by the bottom of the wrapper is a bit overkill, given that we iterate from the bottom. This also prevents the scenario of having no nodes that are not precisely intersected, but possibly straddling the bottom of the wrapper.
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.
It seems that a number of the tests had started failing when run in
Chrome. They were fine under PhantomJS, but the MegolmExport tests only work
under Chrome, and I need them to work...
Mostly the problems were timing-related, where assumptions made about how
quickly the `then` handler on a promise would be called were no longer
valid. Possibly Chrome 55 has made some changes to the relative priorities of
setTimeout and sendMessage calls.
One of the TimelinePanel tests was failing because it was expecting the contents
of a div to take up more room than they actually were. It's possible this is
something very environment-specific; hopefully the new value will work on a
wider range of machines.
Also some logging tweaks.
This increases `UNPAGINATION_PADDING` (see the ASCII on ScrollPanel.js, `_getExcessHeight`), and also debounces unfilling requests made for 200ms. This forces unfilling requests not to be sent unless the next 200ms has no scrolling, effectively.
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
Controls whether a scrollPanel starts off at the bottom.
This may not be necessary and could either be derived from stickyBottom, but
this means I can be sure that the behaviour of ScrollPanel is completely
unchanged for all other uses to avoid breaking any other uses of
ScrollPanel.
Under certain conditions, it was possible to get stuck in a state where any
user-initiated scroll would be met with "Working around
vector-im/vector-web#528" and overridden. Fix this by removing the duplication
between _lastSetScroll and recentEventScroll, and using _lastSetScroll which is
more reliable.
The most recent problem was that we were setting _lastSetScroll whenever we
wrote to scrollTop (and ignoring the next scroll event which matched that
offset), but if there was no change to scrollTop, we wouldn't actually get a
scroll event, so would ignore some future scroll event instead.
Make sure that we only set _lastSetScroll if there's a change to scrollTop.
(Fixes https://github.com/vector-im/vector-web/issues/1162, more)
When the user scrolls up, and scrolls back to where they were, we want to save
the final scroll state. We were ignoring it because it looked the same as the
last autoscroll.
Fixes https://github.com/vector-im/vector-web/issues/1162
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
This adds support for links to particular event ids: add /<eventId> to the URL
for a room.
This commit also ensures that we scroll to the 'read marker' when switching to
a room which has no previous scroll state, as well as preventing that marker
from going past the middle of the screen.
This also reinstates the preservation of scroll state when switching rooms,
which was disabled previously.
Given we want to use isAtBottom to figure out whether to show 'unread messages'
counts, we ought to return the current scroll state, rather than the saved one.
This fixesvector-im/vector-web#576
The dance to avoid doing repeated fill requests on every update is common, so
add it to ScrollPanel. Let onFillRequest return a promise, which prevents any
updates until it completes.
Bruno Windels