* Add test for thread list stability around non-reply updates
* Fix thread list being ordered based on all updates
* Fix test
* Update spec/integ/matrix-client-event-timeline.spec.ts
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Iterate
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Fix tests oversimplifying threads fixtures
* Check for unsigned thread_id in MatrixEvent::threadRootId
* Fix threads order being racy
* Make Sonar happier
* Iterate
* Do not assume that a relation lives in main timeline if we do not know its parent
* For pagination, partition relations with unknown parents into a separate bucket
And only add them to relation map, no timelines
* Make addLiveEvents async and have it fetch parent events of unknown relations to not insert into the wrong timeline
* Fix tests not awaiting addLIveEvents
* Fix handling of thread roots in eventShouldLiveIn
* Fix types
* Fix tests
* Fix import
* Stash thread ID of relations in unsigned to be stashed in sync accumulator
* Persist after processing
* Revert "Persist after processing"
This reverts commit 05ed6409b35f5e9bea3b699d0abcaac3d02588c5.
* Update unsigned field name to match MSC4023
* Persist after processing to store thread id in unsigned sync accumulator
* Add test
* Fix replayEvents getting doubled up due to Thread::addEvents being called in createThread and separately
* Fix test
* Switch to using UnstableValue
* Add comment
* Iterate
* Make a clear and explicit filter on which events are considered for fetchEventsWhereNeeded
* Convert the logic in fetchEventsWhereNeeded to an async function
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* Fetch edits for thread messages
Modifies fetchEditsWhereNeeded to allow edits of threaded messages. The
code before prevented any relations from fetching edits, but of course
events in threads are relations.
We definitely want thread messages to get their edits fetched, and I
assume this is working in the real code, probably because the event
being looked at is some kind of eventmapped thing that doesn't have
proper relations visible on it.
In tests, if we don't make this change, we can't see edits getting
fetched.
* Add a test for fetching edits on demand in a thread
This test demonstrates the current behaviour, which contains a bug - we
don't actually add the right event to the timeline.
* Fix bug where original event was inserted into timeline instead of the edit event
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* Fetch edits for thread messages
Modifies fetchEditsWhereNeeded to allow edits of threaded messages. The
code before prevented any relations from fetching edits, but of course
events in threads are relations.
We definitely want thread messages to get their edits fetched, and I
assume this is working in the real code, probably because the event
being looked at is some kind of eventmapped thing that doesn't have
proper relations visible on it.
In tests, if we don't make this change, we can't see edits getting
fetched.
* Add a test for fetching edits on demand in a thread
This test demonstrates the current behaviour, which contains a bug - we
don't actually add the right event to the timeline.
* Add a test for creating local echo receipts in threads
* Only add local receipt if it's after existing receipt
* Refactor local receipt tests to be shorter
* Tests for local receipts where we DO have recursive relations support
* Fix mark as unread button
* Revert to prefer the last event from the main timeline
* Refactor room test
* Fix type
* Improve docs
* Insert events to the end of the timeline
* Improve test doc
* Attempt a potential workaround for stuck notifs
* Remove TODOs
* Fix backwards logic about server support for MSC3981 in fetchEditsWhereNeeded
* Check for lack of MSC3981 server support before calling insertEventIntoTimeline
* If no parent event is found, insert purely based on timestamp
* Mark temporary methods as internal
* Add `getUserDeviceInfo` to `CryptoBackend` and old crypto impl
* Add `getUserDeviceInfo` WIP impl to `rust-crypto`
* Add tests for `downloadUncached`
* WIP test
* Fix typo and use `downloadDeviceToJsDevice`
* Add `getUserDeviceInfo` to `client.ts`
* Use new `Device` class instead of `IDevice`
* Add tests for `device-convertor`
* Add method description for `isInRustUserIds` in `rust-crypto.ts`
* Misc
* Fix typo
* Fix `rustDeviceToJsDevice`
* Fix comments and new one
* Review of `device.ts`
* Remove `getUserDeviceInfo` from `client.ts`
* Review of `getUserDeviceInfo` in `rust-crypto.ts`
* Fix typo in `index.ts`
* Review `device-converter.ts`
* Add documentation to `getUserDeviceInfo` in `crypto-api.ts`
* Last changes in comments
* Retry processing potential poll events after decryption
* Point `typedoc` at `matrix.ts`, not `index.ts` (#3239)
This gets rid of the rather pointless "default" module in the generated docs.
* Split up, rename, and move `ISecretStorageKeyInfo` (#3242)
* Move SecretStorageKeyInfo interfaces out to a new module
* Replace usages of ISecretStorageKeyInfo with SecretStorageKeyDescription
* Skip clear text non-poll events
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Stop doing O(n^2) work to find event's home
In certain rooms (e.g. with many state changes hidden via user preferences), the
events array presented to `eventShouldLiveIn` may contain 100s of events. As
part of its various checks, `eventShouldLiveIn` would get an event's associated
ID (reply / relation / redaction parent). It would then use `events.find` to
search the entire (possibly large) `events` array to look for the parent. (This
by itself seems sub-optimal and should probably change to use a map.)
For many events in a room, there is no associated ID. Unfortunately,
`eventShouldLiveIn` did not check whether the associated ID actually exists
before running off to search all of `events`, resulting in O(n^2) work.
This changes `eventShouldLiveIn` to first check that there is an associated ID
before proceeding with its (slow) search. For some rooms, this change
drastically improves performance from ~100% CPU usage to nearly idle.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
* Add type to `parentEvent`
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
---------
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Refactor the room key handling method
* Fix the forwarded room key test to use the same user ids.
We have some tests that check if receiving a forwarded room key works.
These claim to use the same user id, but in fact they change the user id
in the last moment before the event is passed into the client.
Let's change this so we're always operating with the same user id.
* Stop requesting room keys from other users
We never accept such room keys, so there isn't a point in requesting
them.
* fixup! Refactor the room key handling method
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* fixup! Refactor the room key handling method
* fixup! Apply suggestions from code review
* fixup! Refactor the room key handling method
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Associate event with thread before adding it to the thread timeline
* Make sure events can be added to thread correctly
* Write initial test case
* Add additional comment for why the code had to be reordered
* Add isEncryptedDisabledForUnverifiedDevices in event.ts
* Add Tests
* Add isEncryptedDisabledForUnverifiedDevices properties to event
* Use WITHHELD_MESSAGES instead of hardcoded string
* Use getter instead of function
* Add documentation
* first cut poll model
* process incoming poll relations
* allow alt event types in relations model
* allow alt event types in relations model
* remove unneccesary checks on remove relation
* comment
* Revert "allow alt event types in relations model"
This reverts commit e578d84464403d4a15ee8a7cf3ac643f4fb86d69.
* Revert "Revert "allow alt event types in relations model""
This reverts commit 515db7a8bc2df5a1c619a37c86e17ccbe287ba7a.
* basic handling for new poll relations
* tests
* test room.processPollEvents
* join processBeaconEvents and poll events in client
* tidy and set 23 copyrights
* use rooms instance of matrixClient
* tidy
* more copyright
* simplify processPollEvent code
* throw when poll start event has no roomId
* updates for events-sdk move
* more type changes for events-sdk changes
* page poll relation results
* validate poll end event senders
* reformatted copyright
* undo more comment reformatting
* test paging
* use correct pollstartevent type
* emit after updating _isFetchingResponses state
* make rootEvent public readonly
* fix poll end validation logic to allow poll creator to end poll regardless of redaction
* first cut poll model
* process incoming poll relations
* allow alt event types in relations model
* allow alt event types in relations model
* remove unneccesary checks on remove relation
* comment
* Revert "allow alt event types in relations model"
This reverts commit e578d84464403d4a15ee8a7cf3ac643f4fb86d69.
* Revert "Revert "allow alt event types in relations model""
This reverts commit 515db7a8bc2df5a1c619a37c86e17ccbe287ba7a.
* basic handling for new poll relations
* tests
* test room.processPollEvents
* join processBeaconEvents and poll events in client
* tidy and set 23 copyrights
* use rooms instance of matrixClient
* tidy
* more copyright
* simplify processPollEvent code
* throw when poll start event has no roomId
* updates for events-sdk move
* more type changes for events-sdk changes
* validate poll end event senders
* reformatted copyright
* undo more comment reformatting
* fix poll end validation logic to allow poll creator to end poll regardless of redaction
* Update src/models/poll.ts
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* correct creator == sender validationin poll end
---------
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Michael Telatynski