Selection never showed. getRowSx set a background on the <tr>, but every
<td> paints background.paper over it, and the hover rule targets cells -
so hover won and selection was invisible. Selection and hover are now
both cell-level rules in DataTable, with selection first so hover layers
on top, and rows carry an `is-selected` class from a new isRowSelected
prop. Uptime, Docker and Infrastructure tables all had the same broken
copy of this; they now share the one implementation, and any future table
gets it for free.
action.selected/selectedHover are defined explicitly and tinted with the
brand, so a selected row reads as chosen rather than dirty. Kept low
(6-11%) so the highlight does not swamp the row, especially in dark mode.
From code review:
- Dropped the Google Fonts @import at the top of index.css. Nothing has
used Inter since the switch to Geist, and it was a render-blocking
third-party request on every load - exactly what self-hosting the font
was meant to avoid on air-gapped installs.
- TextInput's autofill override painted background.default, which used
to equal paper and no longer does, so Chrome-autofilled fields showed
a grey block on white cards. Now paper.
- Sidebar background moved from sx to the bgcolor prop (convention rule
1, and it was a new lint warning), and the backdropFilter dropped -
the background is opaque, so the blur only cost a compositing layer.
- Tab no longer bolds the selected label. That is the same reflow the
ToggleButton change removed, and worse here because the indicator
animates toward a target that moves as the label widens.
- Corrected the StatBox gradient comment: contrastText is white in light
mode but near-black in dark, so the constraint is staying near `main`,
not staying dark.
Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
The network tab warns when Capture can only see a container's own
network namespace, but the condition required EVERY reported interface
to be named lo, lo0 or docker0. A containerised Capture usually also
reports the container's veth under a host-looking name (eth0, ens3,
...), so the common case failed that test and the notice never
appeared - leaving those users with plausible-but-meaningless traffic
and nothing explaining why.
Widening it to "any container-only name present" would have been wrong
in the other direction: a host-level Capture on a machine running
Docker legitimately reports docker0 alongside its real NIC, and would
then have been warned incorrectly.
Interface names alone cannot separate the two cases. What does is that
in the container case nothing carries real traffic, while a genuine
host has a busy NIC. The notice now fires when a container-only
interface is present AND every interface is idle, using a 1 KB/s
threshold - real NICs sit orders of magnitude above it, a container's
veth sits at or near zero.
Checked against six scenarios: the reported case (lo + ens3 + docker0,
all near zero) now warns; a host with a busy NIC plus an idle docker0
does not; a fully namespaced container still warns as before; and a
quiet host with no container-only names stays silent.
The notice text is updated to match, since it previously described
only the all-container-names case and did not explain that a
host-looking interface can be the container's own.
Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
Two small pre-existing bugs in the infrastructure gauges.
Arc overdraw. Gauge computed strokeLength from the raw `progress` prop
while the label and the fill colour both used `progressWithinRange`,
the value clamped to 0-100. A reading above 100% therefore swept the
arc past a full circle - the offset (circumference - strokeLength)
went negative - while the label still read "100.0%". A negative
reading drew the arc backwards for the same reason. strokeLength now
uses the clamped value, so out-of-range input stops at exactly one
turn and matches what the label and colour already showed. Values in
range are unaffected.
The effect that animates the arc also listed `progress` in its
dependency array while only reading `strokeLength`, so it re-ran the
100ms animation on changes that could not alter the arc (105% to 110%,
say). Now that strokeLength is derived from the clamped value, the
stale dependency is dropped.
Disk key fallback. `disk?.device || 0 + idx` parses as
`disk?.device || (0 + idx)` because + binds tighter than ||, so the
fallback was just `idx` and the leading 0 did nothing. It happened to
produce unique keys, but by accident rather than intent, and a disk
whose device is the empty string collided with index 0. Replaced with
a `disk-${idx}` template so the intent is explicit.
Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
The gauge row on the infrastructure details page laid out memory, CPU
and one gauge per disk in a single flex row with no wrapping and no
overflow handling. Each gauge is capped at 260px, so on a host with
enough disks the row ran past the content column.
RootLayout sets overflow: "hidden" on that column, so the excess was
clipped outright rather than becoming scrollable - the later disks
rendered but could not be reached by any means.
Three changes, all scoped to this row:
flexWrap moves the overflow onto additional rows.
useFlexGap is required alongside it. MUI's Stack implements `spacing`
as `& > :not(style) ~ :not(style) { marginLeft }`, and that selector is
DOM-order based rather than line-aware, so the first card of each
wrapped row would carry a spurious 16px left margin and misalign
against the row above. useFlexGap switches to a real flex gap.
flexBasis on the children is what actually makes the line break.
BaseChart sets `flex: 1`, which expands to `flex: 1 1 0%`; wrapping is
decided by the sum of items' hypothetical main sizes, so with a zero
basis that sum is 0 and the row never overflows. The cards would
instead shrink to min-content (roughly the 70px gauge plus the widest
label) and stay on one cramped line. Giving each child a 260px basis
makes the row wrap at the intended card width.
The basis is applied through the row's own `& > *` selector rather than
by changing BaseChart, which has eight other consumers that default to
maxWidth: "100%" and would have had their layout altered.
The repeated 260 literals are now a named constant.
Only affects viewports at or above the md breakpoint; below it the
stack is already a column, where flexWrap is inert.
Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
- Adjust `alignItems` to `stretch` and add `maxWidth` (260) to Gauge components in Infrastructure Details page.
- Update German translations for memory titles, temperatures, and labels in locales file.
The notice now triggers on interface names (loopback / container-bridge
only), not on zero traffic. Update the variable, i18n key, and English
copy to match:
- showNoTrafficNotice -> showLoopbackOnlyNotice
- pages.infrastructure.charts.labels.netNoTraffic ->
pages.infrastructure.charts.labels.loopbackOnlyNotice
- English string rewritten to describe the loopback-only condition
rather than "zero traffic on every interface"
Other locales still hold the old string under the old key and will fall
back to English until the translation pipeline picks up the new key.
Tracked separately.
The notice at the top of the network charts was firing whenever the aggregated
per-second delta was zero across all interfaces. That is a false positive when
Capture is running on a real host but the polling interval is >= 1 minute and
the aggregation bucket is also 1 minute — first == last in the bucket, delta
is zero, but the interface has plenty of real traffic in its cumulative
counters.
Base the notice on interface names instead: only show it when the ONLY
interfaces Capture reports are loopback / container-bridge names (lo, lo0,
docker0). Real NICs (enp0s6, eth0, wlan0, tunN, vethN, brN, etc.) keep the
notice hidden even when the aggregation currently reports zero throughput.
The underlying zero-throughput bug (single-sample buckets producing zero
deltas) is tracked separately.
Adds explicit 'align' support to Table headers to override strict index-based alignment. Restores exact center-alignment spacer boxes to Uptime and Infrastructure tables to match develop branch styling.
Fixes#3602
Resolves maintainer feedback regarding UI/UX layout and prevents code collisions with other PRs by extracting action logic out of the bar component.
Fixes#3602
- Mounts selection checkboxes in UptimeMonitorsTable and MonitorsTable
- Enhances global Table.tsx to cleanly render checkboxes on mobile cards via mobileLabel
- Injects BulkActionsBar into main list views
Fixes#3602
When Capture runs inside a container (typical for Docker Desktop), the
only visible interfaces are loopback, so every bytes_sent/bytes_recv
counter is zero and the charts render as flat lines without any
explanation. Users couldn't tell whether Capture was unreachable, the
monitor was broken, or there was just genuinely no traffic.
Detect the case where checks exist (chart configs were built) but every
interface across every check reports zero bytesSentPerSecond and
deltaBytesRecv, and render a NoticeBanner above the chart grid
explaining it and suggesting Capture be run on the host.
Adds pages.infrastructure.charts.labels.netNoTraffic to all 16 locales.
- New PageHeader component (variant D — grouped icon-pill toolbar):
big title + muted description on the left, Support / Docs /
Changelog as a 3-icon segmented pill on the right with tooltips.
External links open in a new tab.
- BasePage / BasePageWithStates / MonitorBasePageWithStates accept
a headerKey prop; when set, render PageHeader pulling
pages.<headerKey>.header.title and .description from i18n.
When unset, falls back to the existing breadcrumb (no behavior
change for not-yet-migrated pages).
- All top-level pages (uptime, infrastructure, pageSpeed,
notifications, maintenance, statusPages, incidents, logs, checks,
account, settings) now pass their headerKey.
- Sidebar: removed the bottom menu (Support / Discussions / Docs /
Changelog) since those links now live in the page header.
The Open site action in monitor row menus called `window.open(monitor.url)`
unconditionally, which produced unresolvable navigation for monitors
targeting internal services:
- Hardware monitors always point at a Capture agent (e.g.
http://capture:59232/api/v1/metrics) that the user's browser can't
reach.
- Port, ping, docker, game, grpc, and websocket monitors store hostnames
or non-HTTP endpoints, which browsers can't load anyway.
This change hides the action where it can't possibly work:
- Removed entirely from the Infrastructure (hardware) monitors table.
- In the Uptime monitors table, only shown for http and pagespeed
monitor types whose URL starts with http:// or https://.
A more comprehensive fix that adds a separate user-facing siteUrl
field on the Monitor schema is left for a follow-up.
Closes#3434