Promises are now not being resolved within the same tick, so give
another tick for the UI to update after all the HTTP calls have
flushed through. This is fairly terrible, but I can't immediately
see a better way of doing this.
The 'loading' tests only worked when run with the other tests and
failed if you just ran the file by itself, because the skin was
loading in the 'joining' tests, but not here.
For some reason, update webpack causes the promise to no longer
complete by the next tick. Change the test to not depend on how
fast the promise goes through.
Fix scroll up, down pagination test
NB: this test may not fail on Travis, although it did fail locally without a fix: #563.
Once the test has scrolled the panel to the top, to the earliest events, it should be able to forward paginate, because some degree of unpagination occurs. This does assume that unpagination will occur when scrolling to the beginning of the events and that unpagination should allow pagination again in the same direction.
Instead of checking that the first event is no longer the first event (varies due to unpagination), check instead that the most recent event can be seen when scrolling all the way down to the bottom of the TimelinePanel.
Scrolling past the bottom of content seems to have strange behaviour, which isn't a useful part of the test. So now the test will scroll down until the last event instead.
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
The 'should load new events even if you are scrolled up' test was sometimes
failing. It turned out that pagination *sometimes* wasn't starting soon enough
after setting the scrollTop, and awaitPaginationCompletion was incorrectly
believing it to have already been and gone.
Add an awaitScroll to make sure that we wait long enough for the pagination to
begin.
* 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.
1. fix the 'Clean load' tests which had been broken by
https://github.com/matrix-org/matrix-react-sdk/pull/399: make sure we clear
localStorage between tests.
2. Test the session rehydration properly by setting the localStorage rather
than setting up the MatrixClientPeg before loading the app.
3. Add some tests for the auto-guest-registration flows.
Take some of the magic out of MatrixChat.componentDidMount() into a new
component.
Also delete the MatrixChat test. It wasn't really doing much, is broken by the
change, and I am replacing it with (better) app-level tests in the vector
project.
Sometimes it fails because awaitScroll() on :277 isn't resolving because onScroll isn't firing. We need to know if this is because we aren't changing scrollTop
For notification rules, the absence of a value on a 'highlight' tweak means
that the highlight should happen; this was previously confusing us.
Use the action parser from NotificationUtils to simplify the code.
Fixes https://github.com/vector-im/vector-web/issues/1330
* Make sure we only get one js-sdk (and update runtime config to match)
* Don't verifyNoOutstandingRequests (since it is hard to be certain which we
will get, and makes the tests too dependent on implementation-specifics).
* Disable color for npm test, to avoid confusing Jenkins
It turns out that a bunch of things rely on MatrixClient methods to return
promises rather than undefined. Rather than having to undo half the work done
by sinon.createStubInstance, just build our own object with as many methods as
we need stubbed out.
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.
I think this was responsible for the readmarker just disappearing rather than
animating.
While we're here, decrease the delay on the animation, and instead make it take
slightly longer to disappear.
