A session whose recovery state is INCOMPLETE has not got the secrets it
would need to sign another device, so accepting an incoming verification
request from it can only fail. The screen offered "Start verification"
anyway, and the user learnt otherwise at the end of the flow.
Show the design's alert step instead — "Verification with this device is
currently unavailable" — with only the Ignore action, and leave the
request unacknowledged in every other respect.
Part of #5344.
The developer option passes its value through to the widget URL verbatim,
so it has to be the URL of the page that joins a room rather than the
deployment root. That is not obvious from the field, and hughns asked for
it to be written down in docs/ rather than expanded inline in the app,
because the path depends on how the deployment was hosted.
Part of #4475.
The gallery gave no indication of how old the screenshots on the page were,
which is one of the remaining items on the GitHub Pages improvement list.
The generator now writes the time it ran alongside the screenshot data, and the
page renders it in the footer next to the existing links.
The doc told the reader to add disableSslVerification() to
RustMatrixClientFactory.create(), which has not built the client for a long
time; getBaseClientBuilder() is where the chain lives, and it covers both the
login client and the restored session client.
It also only described the emulator's own proxy setting, while the app already
follows the device's global proxy through DefaultProxyProvider, which is the
only way to do this on a physical device.
The timeline renders a message with the sender's raw Matrix ID whenever the
SDK has no profile for them, even though the room member list the same screen
already holds usually knows their display name and avatar.
The timeline item factory now falls back to the room member for a sender whose
profile is not resolved, both when the item is first built and when the member
list arrives afterwards, so the name and the avatar settle on the display name
instead of staying on the ID.
The member suggestions were emitted in whatever order the room member list
happened to be in, so a member who only matches somewhere in the middle of
their name could be offered above one whose name starts with the query.
Matches are now ordered by how well they match: display name prefix first,
then user ID localpart prefix, then any other match. The sort is stable, so
members of equal rank keep the order the member list gave them.
The @room suggestion was also matched case sensitively, so typing @Ro or
@ROOM dropped it while @ro kept it. It now matches the query the same way
the members do.