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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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:
There are 21 other
self.status.setText(...)/_update_status(...)call sites inbcc.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#warnBannermechanism 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 referenced this issue2026-08-03 22:41:03 -04:00