* Do we show the last room correctly on resume?
* Do we show the home page if we have no last room?
* If we follow a login link, and re-log-in, do we correctly vape the
mx_last_room_id (#4283)
To work around the fact that we now do more trips around the
event loop to update view state (because of going vis the store).
Also add comment saying how horrible this is.
The q.delay is needed to make sure (or at least reasonably
sure...) that the login component has appeared by that point. The
done handler needs to be the error callback too otherwise failures
result in timeouts rather than the actual failure.
This time the test wasn't being flaky, but it does inspect a lot of the internal of RoomView, which has had some modifications recently. I've updated the test to reflect this and it passes locally.
Also, fix a bug in HomePage with an undeclared "error" which should be "err".
Let's see what Travis thinks of this!
Two changes:
1. wait longer for /sync to arrive in the loading tests, via an
`expectAndAwaitSync` method.
2. https://github.com/matrix-org/matrix-react-sdk/pull/773 made it possible for
MatrixChat to not show its syncing spinner despite `loading` being
false. Update `awaitSyncingSpinner` accordingly, so that it doesn't fail
when it happens to check MatrixChat at just taht moment.
Depending on timing, the first `httpBackend.flush()` could end up just flushing
a '/presence' call rather than the initial sync. The fix to that is simply to
not set the expectation on /presence.
While we're there, split out the flushes of /publicRooms and
/thirdparty/protocols, so that we can be sure that they happen.
There is probably still a bunch of flakiness there, but this should fix one
particular instance.
* WIP msisdn signin (css)
* Changed how highlights are done
to support keyboard based navigation
* Support for new InteractiveAuth registration
* CSS for msisdn auth entry component
* CSS tweaks for msisdn login
* Fix tests
This test assumed that `/sync` would be called immediately after rendering
`<MatrixChat />` but this isn't true in an IndexedDB world: it bounces via
`store.startup()` first.
It looks like the tests resolve this by adding `q.delay(1)` so that's what
I've done: in the future it would be better to extend `HttpBackend` to have
a `waitFor(req) Promise` function so we can removing timing from the tests.
This seeks to fix the intermittent failure of the "MatrixClient rehydrated from
stored credentials" tests.
The problem appears to be that the 'load_completed' is sometimes taking a while
to come through from the dispatcher - or rather, it is taking a long time to
get *sent* to the dispatcher: the chain of `q().then().catch().done()` in
componentDidMount can take a while to happen.
As a workaround, give the test a few goes when waiting for us to start
syncing. It's not ideal to be poking into the internal state of MatrixChat like
this, but it'll do for now.
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.
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.
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
Richard van der Hoff