Removes one of the two places we use Velocity, so we're one step
closer to getting rid of it for good.
Should therefore fix the fact that Velocity is leaking data entries
and therefore <hr> elements.
Hopefully also makes the logic in getEventTiles incrementally simpler,
if still somwewhat byzantine.
as BACAT scrolling relies on CSS from riot, which is not
included in the karma tests, we're removing these
tests in favor of later adding them to the e2e tests.
Currently, any error in the `GroupStore`s several requests can cause the whole
`GroupView` component to hide and be mark the group as failed to load.
Since it is known that group members may fail to load in some cases, let's only
show failed to load for the whole group when the summary fails.
This also strengthens the `GroupView` test by ensuring we wait for multiple
updates for checking results.
Signed-off-by: J. Ryan Stinnett <jryans@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.
It turns out that Chrome now implements scroll-anchoring itself (ie, content
stays in the same place when you add more stuff off-screen), which means we
cannot rely on back-pagination to make ScrollPanel do a scroll.
Instead, just do a scrollToToken. Which turns out to be considerably simpler
anyway.
This allows for a truely flux-y way of storing the currently viewed room, making some callbacks (like onRoomIdResolved) redundant and making sure that the currently viewed room (ID) is only stored in one place as opposed to the previous many places.
This was required for the `join_room` action which can be dispatched to join the currently viewed room.
Another change was to introduce `LifeCycleStore` which is a start at encorporating state related to the lifecycle of the app into a flux store. Currently it only contains an action which will be dispatched when the sync state has become PREPARED. This was necessary to do a deferred dispatch of `join_room` following the registration of a PWLU (PassWord-Less User).
The following actions are introduced:
- RoomViewStore:
- `view_room`: dispatch to change the currently viewed room ID
- `join_room`: dispatch to join the currently viewed room
- LifecycleStore:
- `do_after_sync_prepared`: dispatch to store an action which will be dispatched when `sync_state` is dispatched with `state = 'PREPARED'`
- MatrixChat:
- `sync_state`: dispatched when the sync state changes. Ideally there'd be a SyncStateStore that emitted an `update` upon receiving this, but for now the `LifecycleStore` will listen for `sync_state` directly.
Add tests that make assertions about the UI during registration when registration is done with a user recognised as a team member (by the mock rtsClient).
- 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
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.
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.
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
