ILAG only works on HSes that allow registering without an email
address, so whenever we redirect to the ILAG flow, check what
registration flows the server supports, and if it doesn't offer one
that's ILAG-compatible, prompt the user to go through the full
registration process instead.
This doesn't change all the entry points into ILAG, I'll do that
in a separate commit.
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.
Emit a piwik event when a decryption occurs in the category "E2E" with
the action "Decryption result" and the name either "failure" or
"success".
NB: This will cause Riot to a lot of networking when decrypting many
events. One HTTP request per decrypted event should be expected.
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
The user might (probably does) have a session even if we haven't actually tried
to load it yet, so wrap the whole loadSession code in the error handler we were
using for restoring sessions so we gracefully handle exceptions that happen
before trying to restore sessions too.
Remove the catch in MatrixChat that sent you to the login screen. This is
never the right way to handle an error condition: we should only display the
login screen if we successfully determined that the user has no session, or
they explicitly chose to blow their sessions away.
The duration measured is between
- componentWillUpdate of MatrixChat and
- componentDidUpdate of MatrixChat.
This does not account for *all* changes to the view that occur
when a room switch happens, for example. But it does at least
capture the difference between switching to a "big" room and
switching to a small test room.
This was for when the new and old versions were available
concurrently on /develop and /app.
The various migration steps are still logged to the console in
js-sdk.
