Piwik supports sending an event value, which we can use to indicate
cardinality of UISIs to be tracked instead of tracking them individually.
This means we can track them at a lower frequency of (fairly arbitrary)
60s.
Instead of pinging Analytics once per failed decryption, add the failure
to a list of failures and after a grace period, add it to a FIFO for
tracking. On an interval, track a single failure from the FIFO.
For setting:
- name
- topic
- history visibility
- power levels
Testing RoomSettings required more stubbing on the matrix client.
The power level tests should be failing at this commit, with
fixes being made in upcoming commits.
Some tests are marked as known failures that we should fix but
aren't necessarily bugs:
- SettingStore.setValue is used when saving despite the user not
having made a change.
- Testing directory publicity changes cannot be tested because we
update state asynchronously in componentWillMount (which we do
not block on in beforeEach).
Also, we needed to use `export default` to make sure everything
uses the same client peg and client.
* Allow the client to run without connection to HS (i.e. using indexeddb)
Allows running without having pushRules (it's safe not to have these
when running from indexeddb sync.)
This means rooms will be displayed with "unknown" notifcation state.
This assumes anything that uses the push rules will get pushRule state
again when the client starts syncing again.
For recovering from being disconnected,
* If an avatar has fallen back, try again on reconnection
* If a thumbnail image failed to load, retry on reconnect
* Load joined groups when reconnecting
Update tests to give MELS a context.matrixClient
Tab-completed @Mentions should only be sent as display names in the `body` of the event. The HTML should be unaffected, and always sent as an anchor tag.
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.
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 stops react-sdk from tracking any state previously stored for the purposes of enabling or disabling the lab feature that enabled the new MessageComposer. It is now enabled permanently.
This is being done with the hope that we can get more feedback for it so that when we release we can be confident that people will be OK with the changes it brings.
When sending the letter "a" we expect it to be sent as a text message when RTE is enabled because we now detect that there is no formatting or styled blocks in the composer. We also expect emoji to be sent as plaintext if there is no formatting
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!
In order to get ILAG internationalised
Conflicts:
src/components/structures/LoggedInView.js
src/components/structures/MatrixChat.js
src/components/views/dialogs/ChatCreateOrReuseDialog.js
src/components/views/dialogs/SetDisplayNameDialog.js
src/createRoom.js
src/i18n/strings/en_EN.json
This allows for the alias resolution to occur before a join is attempted. In theory, join_room could in future do an optional view_room-esque thing before attemping a join which would be less fragile than dispatching things in the right order.
Also, make sure the store indicates that it is not loading when a room ID has been used - no alias resolution need take place.
* Serve translation files from the karma server
* Port UserSettingsStore to ES6 exports because the test runner
gets confused by ES6 importing a commonjs module
* Remove extra spaces in translations strings for MELS
* Fix 'his/her' back to be 'their'
* Change test to expect singular 'invitation' for a single person
(there may be multiple invitations, but IMO this should be
'rejected n invitations' and we can play with the wording later,
I don't think the singular is any worse than the plural).
* set language in the MELS tests (and wait for it to complete)
* Don't bother setting lang in other tests for now
Don't include src in resolve root for the karma test, as otherwise
modules from react sdk get pulled in instead of npm libraries like
'extend' which breaks everything in really subtle ways.
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.
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.
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
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.
By adding a way to wait a short time for a component to appear in
the DOM, so we don't get flakey failures like this when we change
something to returning a promise that needs to resolve before the
component actually appears.
* 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.
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 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.
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.
