Update notification is ephemeral — the status line that announces it gets overwritten by the next UI action #78

New Issue

2026-07-20T12:21:21-04:00

the_og commented

2026-07-20 12:21:21 -04:00

Reported from the field: running v1.2 against a repo with v1.3.0 published produced no update prompt.

Cause

The startup check announces itself into the shared status label and nothing else:

self.status.setText(f"Update available: {release['version']}  ·  Help ▸ About to view it.")

There are 21 other self.status.setText(...) / _update_status(...) call sites in bcc.py. The check runs off-thread and lands whenever the network returns — typically a second or two after the window opens, i.e. right as the user starts clicking. Selecting a server, saving, filtering, or any refresh overwrites the notice. The user gets a message that flashes and disappears, or never appears at all if it lands before the first refresh.

This is exactly the bug fixed for the MSIX warning in #35 ("MSIX warning is ephemeral — wiped by the next status-bar update"), which got a persistent banner. The same fix was never applied to the update notice, which has the same lifetime problem and the same requirement: it must persist until acted on.

Suggested fix

Reuse the QLabel#warnBanner mechanism the MSIX fix introduced — a persistent, dismissible banner rather than a status-line write. It should carry the action with it (a link or button straight to the release page), not tell the user to navigate somewhere else.

Worth checking whether any other transient-but-important message is written to the status line; this is now the second instance of the pattern, so a small helper for "persistent notice" would stop it recurring a third time.

Tests

The notice survives a subsequent _update_status() / _refresh_tables() call.

Reported from the field: running v1.2 against a repo with v1.3.0 published produced no update prompt. ## Cause The startup check announces itself into the shared status label and nothing else: ```python self.status.setText(f"Update available: {release['version']} · Help ▸ About to view it.") ``` There are **21** other `self.status.setText(...)` / `_update_status(...)` call sites in `bcc.py`. The check runs off-thread and lands whenever the network returns — typically a second or two after the window opens, i.e. right as the user starts clicking. Selecting a server, saving, filtering, or any refresh overwrites the notice. The user gets a message that flashes and disappears, or never appears at all if it lands before the first refresh. This is exactly the bug fixed for the MSIX warning in #35 ("MSIX warning is ephemeral — wiped by the next status-bar update"), which got a persistent banner. The same fix was never applied to the update notice, which has the same lifetime problem and the same requirement: it must persist until acted on. ## Suggested fix Reuse the `QLabel#warnBanner` mechanism the MSIX fix introduced — a persistent, dismissible banner rather than a status-line write. It should carry the action with it (a link or button straight to the release page), not tell the user to navigate somewhere else. Worth checking whether any *other* transient-but-important message is written to the status line; this is now the second instance of the pattern, so a small helper for "persistent notice" would stop it recurring a third time. ## Tests The notice survives a subsequent `_update_status()` / `_refresh_tables()` call.

the_og added the P1 label 2026-07-20 12:21:21 -04:00

the_og referenced this issue from a commit

2026-07-20 12:29:38 -04:00

fix: make the update checker visible -- persistent banner + a menu item

the_og referenced a pull request that will close this issue

2026-07-20 12:29:58 -04:00

fix: make the update checker visible — persistent banner + a Help menu item (#78, #79) #81

the_og closed this issue

2026-07-20 12:52:48 -04:00

the_og referenced this issue from a commit

2026-07-20 12:52:48 -04:00

Merge PR #81: make the update checker visible — persistent banner + Help menu item (#78, #79)