Previously only the first child node of a spoiler was considered to
determine if there should be a spoiler reason. This was, unfortunately,
incorrect, as soon as e.g. the reason had more than one space. This is
fixed by properly iterating all child nodes to search for the reason.
I see soo much annoying warnings in the logs since matrix 0.2.0
and to be honest it was never helpful to have this logs. Therefore it seems to make more
sense to make those warnings optional.
The isolates package is discontinued and not compatible
with the newest Dart version.
dart:isolate is not an option because importing this
library makes it impossible to run the matrix
SDK on dart web native. It just won't
build. So we now just depend on
that the flutter app pass through the compute method.
This PR adds support for nicer mentions in markdown: You can now
fetch the mention string of a user with `user.mention` which is
human-friendly (typically contains the display name), which will get
properly pillified upon passing through the markdown parser.
Due to chunked lazy sending of megolm sessions it was in theory that we encrypted two olm
messages to the same device in different futures out-of-order. Introducing locking here should
fix this (increadibly rare, so far only theoretical?) race-condition
If the well-known look fails (not json, 404, etc.) we should assume a
reasonable fallback (domain part with https prepended). As clients are
expected to call Client.checkHomeserver on the resulting domain anyways
we can safely assume this default, as it is still validated, if there
is actually a matrix homeserver running on that endpoint.
If the currentVersion of the database is null then the database has never been used yet.
Therefore we store the current version and do not call the migrate method.
With the switch to hive a regression of sending the to_device key was
introduced: When popping elements .deleteAt(), so deleting at the index,
was used, instead of .delete(), so deleting of the key. As the new events
pushed onto the queue used hives auto increment key, a .delete() is
appropriate here.
You may have missed the last valid loginState from the stream if you
listen too late to it. This makes it possible to
get always the current loginState.
If you call BasicEvent.fromJson the given content is copied first
which recursively makes sure
that the Map is from type
Map<String,dynamic>.
Using just the constructor doesnt have this which can lead that nested Maps in
the content is InternallinkedHashMap and
therefore lead to type errors.