Address Greptile P2 review on PR #4260. Before Chart.js' first
ResizeObserver callback fires the canvas keeps its HTML5 default
size of 300x150. With position: absolute that no longer pushes any
ancestor's intrinsic size, but on a wrapper narrower than 300px the
canvas can still poke past the wrapper for one frame before Chart.js
catches up. Adding overflow: hidden to the relative wrapper clips
that transient overflow and is the pattern Chart.js' own docs
recommend for responsive charts inside flex / grid layouts. No
steady-state behaviour change because the canvas is already sized to
the wrapper once Chart.js takes over; the React tooltip lives
outside this wrapper so it remains visible.
Address Greptile review on PR #4262.
P2 (line 62): the value read back from localStorage was typed as
any and trusted blindly, so a value written by an extension or a
manual edit could end up as the chart's displayMode. Read it once,
keep only 'table' or 'cards', otherwise fall back to null and let
the existing useMobile-driven default decide. Self-correcting on the
next click is no longer necessary because the next render is already
clean.
P2 (line 114): the empty <span /> was a flex placeholder that
existed only to make justify-content: space-between push the toggle
button to the right when allowSearch was false. Drop the span, drop
space-between, and put marginLeft: auto on the inner Row holding the
actions and the toggle. The toggle now hugs the right edge whether
search is rendered or not, with no extra DOM node. style={{}} is
used because the react-zen Row marginLeft prop only accepts spacing
tokens, not auto.
Verified in Playwright at 1400 viewport: the toggle is now flush
with the right edge of the action row, the toggle still flips
between table and cards on click, and a deliberately invalid
localStorage value ({"malicious":true}) is rejected on reload so
the page falls back to the table default.
The react-zen DataTable lays its columns out on a CSS Grid with
fixed pixel widths, so the sum of column widths becomes the table's
max-content. Without an overflow boundary that width propagates up
through the surrounding flex chain into the Tabs panel grid track,
forcing every ancestor wider than the viewport. Dropping in
overflow-x: auto alone is not enough because the wrapper still
stretches to its parent's width, and the parent's width is still
driven by max-content from the table.
Wrap the rendered DataTable in DataGrid in a single-column CSS Grid
sized as minmax(0, 1fr) with overflow-x: auto. The minmax explicitly
caps the wrapper's track at the available 1fr space (instead of
following content's max-content), so the wrapper takes its size from
the layout and overflow-x: auto produces a horizontal scrollbar when
the table is wider than the viewport. No prop changes; every
DataGrid consumer (sessions, websites, links, pixels, boards, team
admin, etc.) gets the behaviour without any caller-side change.
Verified in playwright on the sessions table at 1024 viewport: the
table stays inside the card and exposes a horizontal scrollbar so
all 9 columns are reachable. At 1600 viewport the table fits
naturally and no scrollbar appears.
DataGrid was already injecting displayMode='cards' on small viewports
via useMobile() and leaving it undefined (default 'table') everywhere
else. The user had no way to override either side: someone on a wide
screen who preferred a denser card list could not get there, and
someone on a tablet with a tall narrow window could not force the
table view to keep their layout consistent.
Add a small icon toggle in the DataGrid header row that flips between
table and cards, and persist the choice in localStorage under
umami.datagrid.displayMode. The user choice wins; if there is none,
the existing useMobile-driven default applies. Every DataGrid
consumer (sessions, websites, links, pixels, boards, team admin,
etc.) gets the toggle automatically with no caller-side change.
Verified in playwright on the sessions page: at 1400 viewport the
default is table; clicking the toggle switches to cards and a reload
keeps cards. At 800 viewport the default is cards; clicking the
toggle switches to table even though useMobile would otherwise force
cards. Round trip in both directions works and the choice survives
navigation away and back.
The chart canvas in src/components/charts/Chart.tsx was rendered
directly inside the Box wrapper. Chart.js writes inline pixel sizes
onto the canvas, and while the canvas lives in the normal flow that
pixel width propagates up as min and max content through every flex
parent and into the surrounding CSS Grid track on the Tabs panel.
The track therefore stayed at whatever width the canvas had when the
page first loaded, and the chart could only grow on resize, never
shrink, until the user reloaded.
Wrap the canvas in a position-relative div and position the canvas
absolutely. Out-of-flow elements do not contribute to ancestor
intrinsic sizing, so the wrapper now takes its size purely from the
parent layout. Chart.js' ResizeObserver picks up the wrapper size and
resizes the canvas to fit, in both directions, without a reload.
Verified in playwright with resize 1280 to 800 (canvas 925 to 699)
and 800 to 1400 (canvas 699 to 1117), both without reload, and that
the click-to-toggle legend, the focusLabel hover behaviour, and the
website overview / revenue charts that share this component all
still render and update normally.
Address Greptile P2 review on PR #4259. willBeHidden was derived from
!ds.hidden, but ds.hidden can be set by the focusLabel pass too, so
the dataset flag is not a faithful read of the controlled hidden
state. In a chart that uses both focusLabel and hiddenLabels at once,
the callback could fire with a misleading toggle direction.
Read directly from hiddenLabels instead, with optional chaining so
the new path is a no-op when hiddenLabels is not provided. Behavior
is unchanged for EventsChart (which does not use focusLabel today)
but the controlled state is now the single source of truth.
Address Greptile P1 review on PR #4259. The hiddenLabels loop only
wrote ds.hidden = true and never reset to false when a label was
removed from the set. Toggle-off worked today only because the
focusLabel block above ran first and unconditionally cleared all
ds.hidden when focusLabel was falsy. That block is guarded by
chartData.focusLabel !== null, so any caller passing focusLabel={null}
would skip the reset and leave a stale true on reused dataset objects
across effect re-runs, making un-hide silently fail.
Add an else-if branch to the hiddenLabels loop that resets ds.hidden
to false when the label is not in the set and no focusLabel is
active. Behavior is unchanged for EventsChart (which never passes a
null focusLabel) and the contract of the new props is now independent
of execution order.
Address Greptile review on PR #4257: hex6(key) was parsed twice per
label, once in the sort comparator and once when deriving the
preferred palette slot. Cache the parsed integer in a local hashOf
map so the sort comparator and the slot lookup share one computation
per label, no behaviour change.
Clicking a legend item on the events chart toggled hidden via
chart.current.getDatasetMeta(idx).hidden, which lives on Chart.js's
per-dataset meta object. Each time chartData changed (date-range
switch, refetch, focusLabel update) the second useEffect in Chart.tsx
replaces datasets wholesale, Chart.js regenerates the meta, and the
hidden flags vanish, so previously-toggled-off events came back on
their own.
Lift the hidden state into React. EventsChart owns a Set<string> of
hidden labels and passes it down via a new optional hiddenLabels prop
on Chart, plus an onLegendClick callback for controlled toggling.
Chart re-applies hidden after the existing focusLabel pass so the set
survives every data refresh, and falls back to the original
meta-based behaviour when no callback is provided so other charts
(website overview, revenue) keep their existing semantics.
Verified with the seeded Demo SaaS data: hide signup_started in the
Last 24 hours view, switch to Last 7 days then Last 30 days, the
label stays greyed in the legend and absent from the bars; clicking
again restores it. State is component-scoped, so it intentionally
resets on reload or navigation away from the events page.
Colors in the events-tab chart were assigned by the dataset index from
Object.keys(map), so changing the date range or reloading the page
reshuffled keys and produced a different color for the same event each
time.
Pick the palette slot deterministically from a hash of the label
(hex6 / FNV-1a), and walk the palette greedily in hash-sorted order so
the assignment is independent of the API response order. When two
labels prefer the same slot, the later one steps to the next free
slot, so the visible set of up to 12 events all get distinct colors.
The right shift on the hash sidesteps the FNV-1a low-bit bias mod 12
(FNV prime is close to 2^24).
Both packages are required at runtime but were not declared in package.json:
- react-simple-maps imports prop-types but does not list it as a peer or
direct dependency, so prop-types must be provided by the host project.
- @umami/react-zen lists react-aria-components in peerDependencies, so
the host project must provide it.
These are auto-installed by pnpm 8+ when auto-install-peers is true (the
project default), which masks the issue. They are not auto-installed by
npm or by pnpm with auto-install-peers disabled, causing build failures
on a fresh checkout.
Three bugs in src/tracker/index.js, all empirically reproduced.
1. handleClicks() missed clicks on container elements: closest('a,button')
could not find a non-anchor ancestor with data-umami-event, so a click on
any descendant of <div data-umami-event=...> went untracked. Reworked to
closest([data-umami-event]) so any annotated ancestor matches.
2. handlePush() called new URL(url, location.href) outside normalize()'s
try/catch, so a host page calling history.pushState({}, '', invalidUrl)
would have umami's wrapper throw a TypeError into the host's router.
normalize(url) already handles base resolution and catches parse errors.
3. The history hook ran the umami callback BEFORE native pushState, so a
failed native call (SecurityError on invalid URL, etc.) would still mutate
currentUrl/currentRef and schedule a phantom pageview. Run native first;
if it throws, the callback never fires and tracker state stays consistent.
Bug 2 verified: 4/10 representative click scenarios missed before
(span inside div, deep span inside div, a with no href, button inside a),
all 10/10 tracked after.
Bug 1+3 verified: pushState({}, '', invalidUrl) now leaves tracker state
unchanged (currentUrl unchanged, no phantom pageview).
The INP observer sorted Object.values(interactions) on every event entry,
even though metrics.inp is only read when sendPerformance() flushes.
Defer the sort + p98 computation to flush, and drain queued observer
entries via observer.takeRecords() to capture the most recent
interactions on pagehide/visibilitychange.
Output is identical (same INP value computed). Savings are largest on
interaction-heavy pages and low-end devices where the per-event sort
compounds.
Address Greptile review feedback on #4243.
- Cloud-mode link.updateMany / pixel.updateMany now filter where: { ..., deletedAt: null } so a previously soft-deleted row keeps its original deletion timestamp instead of being restamped with the current time.
- Pre-transaction findMany now selects deletedAt; the Redis invalidation list filters to only live slugs, avoiding harmless but wasted DEL calls for already-soft-deleted entries.
Note: the share.deleteMany cleanup still uses the broad entityId list (not filtered by deletedAt) so that orphan share rows of already-soft-deleted links/pixels are still cleaned up. Filtering the prefetch itself, as Greptile's exact suggestion proposed, would skip those shares while link.deleteMany still hard-deletes the rows, leaving orphan share rows behind. Verified empirically with a 3-scenario reproduction.
deleteUser and deleteTeam left link/pixel/board rows (and their share rows)
in the database after the owner was removed. /q/<slug> and /p/<slug>
also kept serving deleted entries because the routes did not filter
deletedAt and Redis cached lookups for 24h.
- deleteUser: clean up link/pixel/board + shares for the deleted user.
Cloud mode: soft-delete link/pixel, hard-delete board, only userId-owned.
Non-cloud: hard-delete everything matching userId or owned teamIds.
- deleteTeam: same cleanup, scoped to teamId.
- /q and /p route handlers: filter deletedAt: null at the call sites
(not in findLink/findPixel helpers, which would null-deref the
permission checks at src/permissions/link.ts and pixel.ts).
- Post-transaction Redis invalidation mirrors deleteWebsite.
Yan
dependabot[bot]andGitHub
Francis Cao
Francis CaoandGitHub
Mike Cao
Stanislaw
0xSYN.dev
Mike CaoandGitHub