* Show a Message not found placeholder when a replied to message cannot be loaded
When the replied to event could not be fetched, the reply preview rendered the
raw SDK error string in critical styling, and tapping it emitted a focus
request that could never succeed, so the user got a dead end dialog.
Render the localised error_message_not_found string in the neutral italic style
already used for redacted and undecryptable replies, and drop the click handler
for that case. The existing key is reused rather than adding a new one; a "you
do not have access" wording was rejected because this state covers any failure
to load the event, not only a permission problem.
* Update screenshots
* Trigger CI after recording screenshots
---------
Co-authored-by: ElementBot <android@element.io>
The store no longer needs a mutableStateSetOf: an ordinary Set kept in a
mutableStateOf does the same job, and matches DefaultMediaPreviewConfigStateStore.
The Compose state itself has to stay. TimelineProtectionPresenter derives
ProtectionState from the store inside a derivedStateOf, so the set must be a
snapshot object for a reveal to invalidate it and reach the timeline. Backing it
with a plain mutableSetOf leaves the presenter with nothing to observe and it
stops emitting after ShowContent.
The set of revealed event ids lived on TimelineProtectionPresenter, which is
scoped to the room graph. That graph is rebuilt every time the room is opened,
so the set was empty on re-entry and every revealed image was hidden again.
Move it into a session scoped TimelineProtectionStore. The store is in memory
rather than persisted: revealing media is a privacy control and there is no
hide action today, so keeping the reveals for the session leaves restarting the
app as a way to undo one, and the set is dropped on logout.
The account provider search treated its whole input as a host, so a full user
ID was probed as https://@alice:example.org, which never resolves, and the
permissive URL fallback then offered that invalid address as a provider.
Recognise a complete user ID and resolve the homeserver from its server name,
preserving a port when there is one. Input that starts with @ but is not yet a
complete user ID resolves nothing, so no candidate is produced while the user
is still typing. Detection reuses MatrixPatterns.isUserId and UserId.domainName
rather than a new pattern.
When the replied to event could not be fetched, the reply preview rendered the
raw SDK error string in critical styling, and tapping it emitted a focus
request that could never succeed, so the user got a dead end dialog.
Render the localised error_message_not_found string in the neutral italic style
already used for redacted and undecryptable replies, and drop the click handler
for that case. The existing key is reused rather than adding a new one; a "you
do not have access" wording was rejected because this state covers any failure
to load the event, not only a permission problem.
MatrixClient had no way to read or write global account data although the
underlying client supports it.
Add getAccountData and setAccountData to the interface and implement them in
RustMatrixClient using the same withContext/runCatchingExceptions idiom as the
neighbouring methods. The content is the raw JSON string the SDK returns and
accepts: event types are open ended, so a typed wrapper belongs to whichever
caller needs one. Scope is limited to global account data; the room level
variant and the change notification APIs can follow when a feature needs them.
Generating a feature with the Generate Module from Template plugin produced a
module that could not build: features/<name>/api/build.gradle.kts was written
from the impl template, giving the api module a dependency on itself and an
impl namespace.
FeatureModule.json declared BUILD_GRADLE_API and BUILD_GRADLE_IMPL, both
defaulting to build.gradle.kts, and used them as fileTemplates keys. The plugin
resolves keys to filenames before matching, so both collapsed to one key and
the second overwrote the first. The same matching code falls back to a suffix
match on the path, so DefaultXEntryPoint also matched the key XEntryPoint and
was generated from the api template.
Key both by directory, which the plugin supports for exactly this case, and
drop the two now-unused placeholders. The file templates themselves were
correct and are unchanged. The onboarding doc gains a note that an already
imported template must be removed before re-importing, since the plugin keeps
its own copy.
The blocked users list displayed each Matrix ID but offered no way to get it
out of the app, which is what someone who blocked a user for abuse needs in
order to report them onwards.
Long press now copies the Matrix ID and confirms with a snackbar, reusing the
ClipboardHelper and SnackbarDispatcher idiom from the user profile screen. A
short tap still opens the unblock confirmation. The row declares a long click
label so the action is announced by a screen reader. No new string is needed.
The forward and share room picker showed only a display name, so several
direct messages or rooms sharing a name were indistinguishable.
Render a secondary line: the canonical alias when the room has one, otherwise
the other person's Matrix ID for a direct message. No model change was needed,
because heroes is populated only for a direct message with exactly one hero,
so heroes.singleOrNull() is the peer.
The ExoPlayer backing voice messages was built without a wake mode, so it
defaulted to C.WAKE_MODE_NONE and held no wake lock. The CPU was free to
suspend once the screen turned off, cutting playback short.
Build it with C.WAKE_MODE_LOCAL instead. The media is a local file, so no
WifiLock is needed, and android.permission.WAKE_LOCK is already in the merged
manifest. The media viewer players are left alone: they already pause on
ON_PAUSE, so a wake lock there would keep the CPU awake for a player the user
has intentionally backgrounded.
Two of the three modes on the room notification settings screen had
screen-scoped keys; the third reused common_mute, which also labels the Mute
action button on the room details screen. A translator could not fix one
occurrence without breaking the other.
Add screen_room_notification_settings_mode_mute and use it at both places on
that screen. The English value is unchanged, so nothing renders differently.
The action button keeps common_mute, which is the one context where the
generic verb is correct.
The media viewer is edge to edge and the loading progress indicator was the
top-most child of a container that only applied navigation bar padding, so it
was laid out at y=0, behind the status bar and any display cutout.
Give it safeDrawing horizontal and top padding, reusing the idiom already used
by MediaViewerBottomBar in the same file. The inset deliberately does not come
from the scaffold content padding, which collapses to zero when the user taps
to hide the overlay.
Opening an image from the timeline replaces it with a full-screen page
reading "error". Two things go wrong. The viewer already holds the item
that was tapped, but building the surrounding media timeline can fail and
the failure overwrites that cached item, so the picture the user asked for
disappears. And the failure page renders the exception message straight
from the SDK, which is developer text with nothing actionable in it.
Emit the failure only when there is nothing cached, so a viewer opened on
a specific event keeps showing that event and stays usable while the rest
of the gallery is unavailable. Where there really is nothing to show, the
page now uses the same alert icon, title and message as the other error
states in this screen, built from strings that already exist.
The trade-off is that the timeline error is no longer surfaced in the
cache case; it is still logged. Swapping it for a snackbar would need a
new surface in the viewer and is left out.
With several accounts logged in, sending a message from one of them raises
a notification on every other account that shares the room. The device
notifies its owner about something the owner has just done, and the more
accounts share a room the more copies arrive.
Resolve the set of logged-in user ids once per push batch and drop an event
whose sender is one of the other accounts, using the filtered-out result
the notification pipeline already understands, so it is recorded in push
history rather than turned into a fallback notification.
The receiving session is removed from that set, which keeps the change a
strict no-op for a single account and protects the local echo that the
reply action pushes back through the same path. Filtering happens at the
one point that sees every kind of push, so messages, polls, call invites,
ringing calls and room invites are all covered.
Filtering is unconditional and has no setting; multiple accounts sit
behind an experimental flag that is off by default, so nothing changes for
a stock build.
A fediverse handle such as `@name@server.tld` contains a substring that
`Linkify.EMAIL_ADDRESSES` recognises as a valid address, so the timeline
renders `name@server.tld` as a tappable `mailto:` link. Tapping it opens a
mail composer addressed to an account that does not accept mail.
Drop a newly added `mailto:` span when the character immediately before it
is `@`. This mirrors what Android already does for web URLs, where
`Linkify.sUrlMatchFilter` rejects a match preceded by `@` — which is why
the handle currently produces exactly one stray mailto span and no partial
link is left behind once it is removed.
Author-supplied links are unaffected: spans that were already present
before linkification are excluded from the check and restored as before. A
genuine address written directly after an `@` — "mail me @support@element.io"
— is no longer linkified, which is the same trade-off Android already makes
for web URLs.
Benoit Marty
renovate[bot]
hayaksi1
Eklavya Jandial
ElementBot
Benoit Marty
Benoit Marty
ganfra
ganfra
ElementBot