NSMenuItem.setImage stretches the row to the leading image's pixel
size regardless of the surrounding rows, so any non-empty bitmap on
the About entry made it visibly taller than the rest of the tray
menu — leaving 16, 18 or 22 px versions all looking wrong next to
the unadorned rows above and below.
Drop the macOS brand mark and gate the SetBitmap call on a non-empty
byte slice; iconMenuNetbird is now nil on macOS, so the About row
falls back to text only. Windows and Linux still ship the brand mark
through their per-platform embed files.
The Windows menu renderer paints leading bitmaps into the Win32
check-mark slot (SetMenuItemBitmaps), which differs from how Cocoa
and GTK handle NSMenuItem.image / menu-row icons:
- SM_CXMENUCHECK sizing: Windows expects ~16x16 at 100% DPI in the
check-mark slot and visually overflows the row for anything bigger.
- Disabled-state mask: Windows desaturates both the row text and the
bitmap when MFS_DISABLED is set, so a disabled informational row
renders the coloured status dot in greyscale.
Per the platform icon guidelines:
Platform | Size | Notes
---------|----------------|-----------------------------------------
Windows | 16x16 | check-mark slot, status row stays enabled
macOS | 22x22 (18-22) | NSMenuItem leading image, HIG
Linux | 24x24 (22-48) | GTK4 menu-row icon channel
Changes:
* Split the menu-row icon embeds into icons_menu_{windows,darwin,linux}.go
so each platform pulls its own size; the brand mark is rendered from
assets/svg/netbird-menu.svg (new vector source) at 16/22/24 px with
Inkscape, and the Windows status dots ship as 8x8 content centred on
a 16x16 transparent canvas (the renderer upscales the bitmap, so the
padding keeps the dot visually proportional to the row text).
* Introduce statusRowEnabled() in tray_status_enabled_{windows,other}.go:
true on Windows so the disabled-state mask does not strip the dot's
colour; false on macOS/Linux where disabled menu rows fade the label
without desaturating the leading bitmap, signalling that the row is
informational.
* Add an icon to the About submenu using the same brand mark.
The main-window toggle stayed visually stuck on "Connecting" when the
user clicked Connect in the UI and then clicked Disconnect in the
tray (or the daemon was otherwise cancelled mid-Connecting).
Repro: open the main window, click the toggle to Connect, then while
the daemon is still in Connecting click Disconnect in the tray menu.
The tray and daemon agree the session is Idle, but the React toggle
keeps painting "Connecting" until the next manual interaction.
Root cause is in ConnectionStatusSwitch.tsx. The component holds an
`action` latch ("connect" | "logging-in" | "disconnect" | null) so the
toggle can show an optimistic transitional state while the daemon
catches up. The connState memo treats `action === "connect"` plus any
non-Connected daemon state as Connecting:
if ((action === "connect" || action === "logging-in") &&
daemonState !== "Connected") {
return ConnectionState.Connecting;
}
The effect that releases the latch only cleared it on `Connected` or
`DaemonUnavailable`. There was no branch for "the connect flow was
cancelled externally and the daemon is back at Idle", so the latch
remained set forever and the optimistic Connecting state never
collapsed.
Fix: add a `sawConnectingRef` that flips to true the first time the
daemon reports Connecting during an active "connect" action, and
resets when `action` returns to null. When `action === "connect"` and
the daemon flips from a state we'd observed as Connecting back to
Idle, clear the latch so connState falls through to Disconnected.
Other paths are untouched:
- Successful connect still clears on Connected.
- NeedsLogin still hands off to driveLogin.
- DaemonUnavailable still clears via the `unreachable` branch.
- The `"logging-in"` action is intentionally not handled here; Login's
internal Down flaps the daemon through Idle and driveLogin's
.finally remains the sole clearer for that latch.
- The `"disconnect"` action's Idle/Disconnected/unreachable clear is
unchanged.
The daemon returns gRPC errors whose message is a wrapped mgm + JWT
stack (e.g. "invalid jwt token, err: token could not be parsed: ...").
Showing that in a native dialog is unreadable. Connection now maps the
substrings it recognises to a ClientError{code, short, long} so the UI
can render a localised summary plus a Details: block carrying the raw
daemon text. formatErrorMessage on the TS side reads the structured
payload from Wails' Error.cause (or the JSON-stringified Error.message)
and falls back to plain Error.message for callers not yet migrated.
Also bumps Wails to v3.0.0-alpha.95.
Adds an end-to-end SSO session-extension feature: the management server
publishes per-peer session deadlines on every Login/Sync, a new
ExtendAuthSession RPC refreshes the deadline using a fresh JWT without
tearing down the tunnel, and the daemon tracks the deadline locally so
the UI can fire a T-10min warning toast with an interactive "Extend now"
action.
Wails v3 alpha.94 switched its default Linux backend from GTK3 +
WebKit2GTK 4.1 to GTK4 + WebKitGTK 6.0 (the GTK3 path is now gated
behind a `gtk3` build tag). cgo files that the binary, the tests, and
the lint job all parse now request `pkg-config --cflags gtk4
webkitgtk-6.0 ...`, so the existing libgtk-3-dev + libwebkit2gtk-4.1
apt deps no longer satisfy them — lint, unit tests, and the linux
release build all fail with `Package 'gtk4' ... not found`.
Replace the apt deps across the four workflows that build/lint the
client tree (golangci-lint, golang-test-linux, release, and the wasm
lint job that also walks client/) with libgtk-4-dev + libwebkitgtk-6.0-dev
+ libsoup-3.0-dev. Both packages are available from jammy (22.04 LTS)
onwards, so existing ubuntu-22.04 runners stay valid.
client/installer.nsis:317 calls `File "MicrosoftEdgeWebview2Setup.exe"`
and client/netbird.wxs references the same payload. In the release
pipeline that file is generated by `wails3 generate webview2bootstrapper`
inside netbirdio/sign-pipelines; the netbird repo's test_windows_installer
job never ran that step, so makensis aborted with:
Error in macro nb.webview2runtime on macroline 21
Error in script "...\client\installer.nsis" on line 325
Mirror the sign-pipelines recipe: set up Go, install wails3 (version
derived from go.mod so the bootstrapper always matches the linked
runtime), then stage the bootstrapper into client/ before the makensis
step runs.
Picks up alpha.92..94 fixes; the binding generator and the
@wailsio/runtime npm package (pinned to "latest") stay compatible.
Brings tranzitive upgrades along (go-git, golang.org/x/exp,
golang.org/x/mod, golang.org/x/text, golang.org/x/tools, pjbgf/sha1cd).
The release_ui_darwin job builds the macOS UI bundle from
.goreleaser_ui_darwin.yaml, but cccb0e92 only added the wails3 CLI
install + bindings-regen hook to the Linux side (release.yml release_ui
job and .goreleaser_ui.yaml). The darwin counterpart still ran pnpm
build against the gitignored, empty bindings/ directory and failed with
~40 TS2307 "Cannot find module '@bindings/...'" errors.
Mirror the Linux setup on darwin: install wails3 from the version
pinned in go.mod, and run `wails3 generate bindings -clean=true -ts`
as the first goreleaser before-hook so vite can resolve @bindings/* by
the time pnpm build starts.
* [management] Add metrics for peer status updates and ephemeral cleanup
The session-fenced MarkPeerConnected / MarkPeerDisconnected path and
the ephemeral peer cleanup loop both run silently today: when fencing
rejects a stale stream, when a cleanup tick deletes peers, or when a
batch delete fails, we have no operational signal beyond log lines.
Add OpenTelemetry counters and a histogram so the same SLO-style
dashboards that already exist for the network-map controller can cover
peer connect/disconnect and ephemeral cleanup too.
All new attributes are bounded enums: operation in {connect,disconnect}
and outcome in {applied,stale,error,peer_not_found}. No account, peer,
or user ID is ever written as a metric label — total cardinality is
fixed at compile time (8 counter series, 2 histogram series, 4 unlabeled
ephemeral series).
Metric methods are nil-receiver safe so test composition that doesn't
wire telemetry (the bulk of the existing tests) works unchanged. The
ephemeral manager exposes a SetMetrics setter rather than taking the
collector through its constructor, keeping the constructor signature
stable across all test call sites.
* [management] Add OpenTelemetry metrics for ephemeral peer cleanup
Introduce counters for tracking ephemeral peer cleanup, including peers pending deletion, cleanup runs, successful deletions, and failed batches. Metrics are nil-receiver safe to ensure compatibility with test setups without telemetry.
* [management] Fence peer status updates with a session token
The connect/disconnect path used a best-effort LastSeen-after-streamStart
comparison to decide whether a status update should land. Under contention
— a re-sync arriving while the previous stream's disconnect was still in
flight, or two management replicas seeing the same peer at once — the
check was a read-then-decide-then-write window: any UPDATE in between
caused the wrong row to be written. The Go-side time.Now() that fed the
comparison also drifted under lock contention, since it was captured
seconds before the write actually committed.
Replace it with an integer-nanosecond fencing token stored alongside the
status. Every gRPC sync stream uses its open time (UnixNano) as its token.
Connects only land when the incoming token is strictly greater than the
stored one; disconnects only land when the incoming token equals the
stored one (i.e. we're the stream that owns the current session). Both
are single optimistic-locked UPDATEs — no read-then-write, no transaction
wrapper.
LastSeen is now written by the database itself (CURRENT_TIMESTAMP). The
caller never supplies it, so the value always reflects the real moment
of the UPDATE rather than the moment the caller queued the work — which
was already off by minutes under heavy lock contention.
Side effects (geo lookup, peer-login-expiration scheduling, network-map
fan-out) are explicitly documented as running after the fence UPDATE
commits, never inside it. Geo also skips the update when realIP equals
the stored ConnectionIP, dropping a redundant SavePeerLocation call on
same-IP reconnects.
Tests cover the three semantic cases (matched disconnect lands, stale
disconnect dropped, stale connect dropped) plus a 16-goroutine race test
that asserts the highest token always wins.
* [management] Add SessionStartedAt to peer status updates
Stored `SessionStartedAt` for fencing token propagation across goroutines and updated database queries/functions to handle the new field. Removed outdated geolocation handling logic and adjusted tests for concurrency safety.
* Rename `peer_status_required_approval` to `peer_status_requires_approval` in SQL store fields
- Peers.Get returns Status{Status: DaemonUnavailable} on Unavailable
instead of an error so the React useStatus initial refresh picks up
the same string the live event stream emits — the overlay no longer
depends on receiving the synthetic event during boot.
- ProfileContext.refresh swallows Unavailable so the redundant
"Load Profiles Failed" popup does not overlap the overlay.
- Tray Profiles submenu is disabled while the daemon is unavailable,
matching the existing settings/debug/connect gating.
- gRPC client uses a 5s ConnectParams MaxDelay; the default 120s cap
was keeping the SubChannel in backoff for tens of seconds after the
daemon came back, masking the recovery.
Brings two main-side PRs' UI behavior across the Fyne→Wails rewrite:
- #5631 (IPv6 overlay support): add "Enable IPv6" row to the polished
SettingsNetwork tab; the legacy screens/Settings.tsx already had it,
but modules/settings/SettingsNetwork.tsx (the user-visible Settings
window) was missing the toggle.
- #6150 (mirror v4 exit selection onto v6 pair): replace the literal
"0.0.0.0/0" || "::/0" filter in screens/Networks.tsx with an
isDefaultRoute() helper that handles the daemon's merged-range
display string (e.g. "0.0.0.0/0, ::/0"), so paired v4/v6 exit
nodes are classified correctly.
When closing go routines and handling peer disconnect, we should avoid canceling the flow due to parent gRPC context cancellation.
This change triggers disconnection handling with a context that is not bound to the parent gRPC cancellation.
