_positionTimer is started when playback begins, but it isn’t cancelled in dispose(). This can leave a periodic timer running after the widget is unmounted (even if the callback checks mounted). Cancel the timer in dispose() to avoid a leak.

The desktop Player listeners (including the new polling fallback) are only registered when controller == null. If a cached controller is reused from audioPlayersDesktop, this widget won’t subscribe, so position/isPlaying won’t update and the #2570 fallback won’t run. Consider always (re)subscribing with per-widget StreamSubscriptions (and cancelling them in dispose()), even when reusing a cached controller.

When a Firebase URL is fetched, it’s applied to SettingsSvc.settings.serverAddress.value immediately. If that Firebase URL is stale/unreachable, subsequent reconnect cycles compare against the already-switched currentUrl and will never revert to the user’s original URL, effectively getting stuck on the bad value for the session. Consider keeping the previous URL and reverting if the trial connection doesn’t succeed, and compare using the full configured server address (not just HttpSvc.origin) so path-only differences don’t break the logic.

authorizationForScopes/authorizeScopes can return null (e.g., user cancels), but the code unconditionally dereferences authorization.accessToken. Please handle a null authorization explicitly and surface a clean "sign-in cancelled" / "no token" path instead of relying on a thrown null-deref.

Ideally, this highPerfMode check should be part of the UrlPreview widget, so it can be managed within, rather than as a one-off

Doesn't latestMessage represent a "cached" version of the latest message state, relative to the current Chat object? Should we make it dbLatestMessage so we fetch the latest message each time? Might utilize more resources, but would be more accurate?

_sendWithDelay() doesn’t cancel an already-scheduled _sendDelayTimer when sendDelay is 0. If the user previously triggered a delayed send (or changes the setting), an old timer can still fire later and send unexpectedly. Consider always cancelling _sendDelayTimer at the start of _sendWithDelay(), including the delay == 0 path.

In the chat-creator keyboard handler, Enter/NumpadEnter still calls sendMessage() directly, bypassing the new _sendWithDelay() logic. This makes sendDelay behave inconsistently depending on context. Use the same delayed-send path here (or explicitly document why chat-creator should ignore the delay).

baseUrl/socketPath return originOverride (or /socket.io) when localhost detection is active. That drops any user-configured sub-path (e.g. https://example.com/bb) and can break reverse-proxy deployments when an origin override is set. Consider preserving the configured path prefix when applying originOverride (e.g. originOverride + sanitizedPathFromServerAddress) and using it consistently for socketPath as well.

c.dbLatestMessage queries the DB every time it’s accessed. In this block it’s invoked once to refresh and again inside the if condition, causing a redundant second query. Store the result of the first call in a local variable and reuse it for the GUID comparison (and for any later reads).

In high-performance mode this widget returns a plain Text without the InkWell tap handler used elsewhere. For location previews (widget.file != null) this removes the ability to open the URL, and even for normal previews it renders as a link but isn’t interactive. Wrap the high-perf fallback in the same tap behavior (or at least preserve it when _data.url is non-null).

Can we take this out of the build method and put it into a getter or separate function. Just pedantic stuff

Not sure if we want to hijack SMS/MMS deep links without formally supporting SMS. I'll defer to @zlshames here.

I would go about this a different way... we should just show a plain old message bubble widget with the url instead of a preview widget. No code necessary in this file.

In the current state, this would not even allow the user to tap and open the link.

We would definitely want some sort of UI logic when implementing this to inform the user its the send delay setting, and allow the message to be user-cancelable.

Are there defined error classes within AudioRecorder or RecorderController? Looking at the string representation of the error is not ideal... but if we have to, it is what it is