This changes the "relations created" event to ensure it is properly emitted even
if the target event is added to the timeline after the relation event. There was
perhaps always a risk of this happening in the past, but is seems more likely to
bite now with delayed decryption.
Part of https://github.com/vector-im/element-web/issues/17461
The `Relations` model was relying on object reference equality to prevent
duplicates, which breaks down if we ever have two objects that represent the
same event.
This fixes things to additionally track event IDs we've seen before and discard
any attempts to add them twice.
Fixes https://github.com/vector-im/element-web/issues/11161
This is a revised version of
https://github.com/matrix-org/matrix-js-sdk/pull/1472 which was previously
reverted for causing security prompts to appear on device list sync. In this
version, we only allow private key requests (which are likely to trigger user
dialogs) if we are coming from the bootstrap path.
This allows sessions that have already synced cross-signing public keys but
never got the private keys for some reason to make forward progress when e.g.
the user triggers bootstrap from security settings.
Depending on the number of users in the request, the server might
overload. To prevent this, the download is broken into chunks of
250 users each. Additionally, no more than 3 requests are kicked off
at the same time to avoid running into rate limiting. Responses are
processed once all chunks have been downloaded.
Fixes: #1619
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
This reworks tracking the Olm sessions a particular task is updating to avoid
deadlocks. By ensuring we synchronously mark all sessions a task cares about as
in progress from the start, we know that no other tasks will own updating a
session in common, which avoids deadlocks across multiple tasks that might be
working on a shared set of devices.
Fixes https://github.com/vector-im/element-web/issues/16194
The main bug here was a race on the callee side because we await-ed
on setRemoteDescription before setting the opponent party ID, and
while we were await-ing, the callEventHandler could give us candidate
events which we'd duly ignore because we thought the party ID didn't
match.
This also meant that any candidates that arrived before the answer
would have been ignored. Save these up by party ID and then add the
ones from the party ID that we pick once the answer comes in.
Also fix the confusion on party IDs where we weren't sure whether
we hadn't picked an opponent or we'd picked an opponent without a
party ID. It's now undefined for the former and null for the latter,
as it claims to be in the comment.
Don't send events all the way via the mock HTTP backend: we're not
trying to test that here. This meant we weren't actually getting
into the right state because the request to send the invite never
actually returned. Now this works, we need to clear the invite timer
otherwise jest has a timer hanging around at the end of the test
(plus we should be doing it anyway).
Typescript tests basically just appear to work, apart from needing
the jest types imported so the typescript checker knows what's what.
DConvert the webrtc test to typescript, which actually mostly just
serves to point out that we're not mocking the whole of `document`,
but oh well.
Send party_id on events and check the party_id of incoming events matches
Includes a basic test to assert that it actually does: we should
build out a decent test suite for calls as there's a lot of edge-case
functionality that can break and slip through the cracks (eg. glare).
This is a start.
Fixes https://github.com/matrix-org/matrix-js-sdk/issues/1511
This untangles cross-signing and secret storage setup into separate path that
can be invoked independently. There is no functional change with this patch, but
instead this just separates one giant monster API into two.
Part of https://github.com/vector-im/element-web/issues/13895
In order to handle auth errors (such as incorrect passwords), we need to ensure
we only try to upload cross-signing keys from within the auth flow helper
function.
This rearranges things to store that function in the builder to use it when the
actual upload happens.
J. Ryan Stinnett