Supply a server config to the component and adjust the wait logic to be less of a race. The Login component will noop onPasswordLogin if it is "busy", and it is busy when it requests the login flows.
The new storage consistency work expects a crypto store exist together with
local storage. This updates the loading tests to create them together.
Needed for https://github.com/vector-im/riot-web/issues/9109
This changes the way tests wait for login to complete from a timer-based system
(which can cause intermittent failures) to an action-based system. The lifecycle
code dispatches the action `on_logged_in` when login completes which we can wait
for in the tests as a much better indication that work is done.
`Promise.defer` is deprecated in Bluebird and it logs loudly each time it's
called. This cleans up testing logs significantly by converting away from it.
Chrome seems to take ages (like, 1500ms regularly) to clear out the indexeddbs,
and that's causing test timeouts. Bump the timeout to hack around it.
Also: clear both dbs in parallel (can't hurt, right?) and improve diagnostics
on the process.
Mostly this is just making it look at the `view` state rather than the
individual boolean flags.
One other tweak merits explanation: we now implement the initial
couldn't-register-as-guest login with an explicit switch to the LOGIN view,
which means that the URL gets updated to #/login.
Treat the waitTime passed into `flush` as a timeout rather than a
time-between-loops, so that we can pass in bigger times and not slow the tests
down too much.
Bump the timeout when waiting for /publicRooms and /initialSync in the joining
test.
This used to exist to reproduce the functionality in the window.onload handler
in vector/index.js -- which got removed in 31915db. Having it here is confusing
at best.
Try to make it a bit more obvious what's been going on in mock-request: add
timestamps to lines, and an identifier so that where we have two flushes in
parallel, we can see what's what.
* 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
