Acting on the review of #622. Two bugs, both real, and the second one is a
test of mine that could not fail for its stated reason.
The stack props were set BEFORE `{...props}`, so any call site passing
`closeOnEscape` overwrote the stack's decision and re-armed Mantine's
window-level Escape listener on a modal that is not on top -- reinstating the
bug the change exists to fix. Three call sites pass it: CollectionReorganizeModal
and BatchReorganizeModal disable Escape while a reorganize runs, Flasher while
it writes an image. The concrete breakage is the one place the app really does
stack two modals: ConflictResolutionModal opens as a sibling above the
reorganize modal, so the moment the reorganize finished and `closeOnEscape`
returned to true, one Escape closed both. They are now destructured out and
composed -- `isTop && closeOnEscape` -- because "only the top modal answers
Escape" and "do not dismiss me while I am busy" are both true. Mantine's own
Modal.Stack applies its stack props after the caller's for the same reason.
Two Cypress cases, one per direction; planting the old order reddens the first.
`Confirm` was still passing Mantine's raw `sm`, and the audit guard I added in
the same PR was supposed to catch exactly that. It did not, and the reason is
worse than the miss: the scanner matched `<Modal\b[^>]*?\bsize='...'`, and
`onClose={() => ...}` contains a `>`, so it stopped at the arrow and never saw
the rest of the tag. It read 44 of the 56 modals that declare a size; the
twelve it skipped included the single offender in the codebase, in this very
file. A guard that scans a fifth of nothing looks identical to a clean
codebase. It now walks the tag with a paren counter, accepts either quote
style, and asserts it scanned more than fifty tags first -- so a scanner that
silently matches nothing fails instead of passing. Confirm says `tiny`.
Also from the review: a bare `expect(titles()).to.not.include('Parent')` in the
Cypress spec ran during the synchronous phase, before any cy command executed
and while nothing was open, so it always passed and guarded nothing. Deleted
rather than repaired -- the retried assertion above it already makes the claim.
An unregistered-but-open modal reported `isTop` even with a parent registered,
which gave both the same z-index for the frame before the effect ran -- a visible
flash of the wrong modal in front. It is only top now if the stack is empty.
Nit: the comment claimed Mantine ignores unknown size names. It ignores unknown
SEMANTIC names and falls back to 440px; it recognises and honours its own. Two
different hazards, both silent, and the comment now says which is which.
1124 jest / 62 suites, 10 in modal-stack.cy.js, 196 in ui-layout.cy.js,
clean npm run build.
Two things, both reported from the running app.
Nested modals could not exist. Mantine binds a window-level keydown listener
per open modal, gated only on whether that modal is open -- nothing checks which
one the user is looking at:
useWindowEvent('keydown', (event) => {
if (event.key === 'Escape' && closeOnEscape && ... && opened) onClose();
}, {capture: true});
Two open modals meant two listeners, so one Escape closed both. Reproduced on
the dashboard: the download modal plus the search modal over it, one press, both
gone, back to the page. Both also sat at z-index 200, so which one drew on top
was DOM order rather than which the user opened.
Mantine's own answer is Modal.Stack with a stackId, which is the only thing that
gates closeOnEscape. Not used, for two reasons: every call site would have to
be rewritten to hoist its modal into a stack, and it sets `__hidden` on
everything below the top -- the parent disappears while the child is open. The
parent should be dimmed and still there, as it was before the migration.
So the wrapper keeps the register itself: a module-level list of open modals,
most recent on top, from which each modal takes closeOnEscape, trapFocus and a
z-index two above its parent. Module-level rather than React context because
the two modals in the bug are not nested in the JSX at all -- the search modal
is rendered by KeyboardShortcutsProvider near the app root and the download
modal by the dashboard. They are siblings that happen to be open together, and
no context relates them. The increment is small on purpose: Mantine puts
popovers at 300, and a stack that climbed past it would paint over the select
dropdowns inside its own forms.
Widths: Roland audited the modal list and chose sizes against Mantine's scale.
Sixteen get wider -- twelve to `large` (620), four to `fullscreen` -- and eleven
keep the width they had, with the size now written down so the decision is in
the source rather than in a default. Flasher was passing Mantine's raw `sm`,
which worked but bypassed the naming the audit used; it says `tiny` now.
The size table itself is guarded, because it is the single thing that halved
every modal during the migration and a quiet edit to it moves seventy at once.
Semantic's widths, measured on the pre-migration build still running on the QA
Pi: mini 360, tiny 540, small 720, large 1080, no-size 900. Mantine's, read out
of its stylesheet: 320/380/440/620/780. A `small` modal went 720 -> 440 and one
with no size went 900 -> 440. Three cases now hold the scale, the mapping, and
the rule that no call site may name a size the table does not know -- an unknown
name is passed to Mantine, ignored, and silently rendered at the default.
Tested in a real browser: none of it is visible to jsdom -- the listener is on
window with capture, the stacking is z-index, and "still visible behind" is
geometry. Note that `should('be.visible')` is the wrong assertion for the
parent: it is an occlusion check, so a child drawn correctly over its parent
trips it. The test uses a wide viewport and asserts the parent is rendered and
shows to both sides of the child. Planting the pre-fix behaviour reddens three.
1124 jest / 62 suites, 8 in modal-stack.cy.js, clean npm run build. The 12
failures in Tags/Channels/Download/Inventory.cy.js are the known pre-existing
Semantic-era selector failures, unchanged.
Acting on the review of #621. No bugs were found; these are the four
suggestions and two nits.
The real one: measurement accepted only hex. `relativeLuminance` returned 0 for
anything else, which is black's luminance and indistinguishable from it -- so a
token written `rgb(92 79 168)` measured as pure black, the "best" foreground was
chosen against a colour the theme does not contain, and the wrong hex was then
frozen into an inline style where CSS could no longer correct it. Silent, and
worse than not measuring. `parseColor` now reads `rgb()`/`rgba()` in both the
comma and space forms, percentages, and `#rgba`/`#rrggbbaa`; `isMeasurable` lets
a caller tell "unreadable" from "black"; and navColorsFrom falls back to the
tokens when the background or every candidate is unreadable. Unreadable
candidates are filtered rather than the whole measurement abandoned, so one
oddly written token does not cost the other two. This matters because the
header claimed custom YAML themes get correct foregrounds for free, and a
hand-written palette is exactly where a non-hex value will first appear.
The Cypress inverse hardcoded night's `--btn-text` as `#0a0000`. The unit tests
parse tokens.css precisely so a palette edit cannot leave a stale claim behind,
and that literal was the one place the rule was broken. It reads the token from
the theme now, asserts it resolved, and additionally pins that red still takes
`--btn-text` while brown no longer does.
Documented rather than changed: the warning indicators still pick their colour
from the `conflictingColors` name list. It is the same defect as the one fixed
here and measurably worse -- `--danger` and `--warning` are 1.0-1.8:1 against
the bar in every theme, light and dark included, because a red icon on a red bar
is a red icon on a red bar. The fix is not a better colour: severity has to
stay distinguishable from the bar's text as well as from itself, and a
monochrome theme has no third brightness, so it has to stop being a hue. That
is a redesign, and the note now sits beside the residue in navColors.ts rather
than only in a PR description. The gallery draws the indicators as the bar
draws them when nothing is wrong; it does not stage a fake overheating Pi to
exhibit a fault nobody has agreed how to fix.
Also documented: re-measurement is triggered by `data-theme`, so a future
custom-theme editor patching custom properties in place would leave the bar on
the values it last measured. There is no event for "a custom property was
assigned" to observe instead, so the note says what such an editor must do.
Nits: "Eleven" in a comment where the assertion locks ten (and a stale 2.91:1
beside it, now 3.27:1), and a missing space in `const wrolpiIcon =<img`.
Six new unit cases, planted: dropping the fallback reddens two.
1121 jest / 62 suites, 196 in ui-layout.cy.js, clean npm run build.
Four faults, each measured in the running app before and after.
The search glyph carried Semantic's `item` class, which has had no rules at all
since Semantic was removed: no pointer cursor, no hover, and an 18.6px hit area
against a 54.4px bar. It is the same kind of thing as Help and Admin and now
takes the same class. The share glyph did compute `cursor: pointer` -- it is an
`<a href>` -- but its target was the 24px box the icon occupies, so the pointer
appeared only if you found it exactly. Corner anchors now stretch and pad like
a link.
The More button rendered with NO class at all: a bare grey UA button while the
rest of the bar took the user's colour. Menu.Target clones its child and hands
it a className of its own, and the trigger spread those cloned props after its
own `className` attribute, so the clone replaced ours. It is merged now. This
was mine, from extracting NavDropdownTrigger last commit -- and it also made the
previous commit's "measured and drawn are the same component" claim only half
true, because the hidden placeholder is not cloned and so kept its class.
The bar still wrapped, for a reason the padding fix could not reach: the corner
does not keep a constant width. The Cmd-K hint renders only once
useKeyboardDetected has seen a keypress, so it appears at an arbitrary later
moment and widens the corner by ~30px; the load, memory, temperature and drive
warnings come and go with the machine's state. None of that resizes the
container, which was the only thing observed -- so nothing recalculated. That
is the other half of "at certain widths": the same viewport wrapped or not
depending on whether the user had touched a key. The corner and the home link
are observed too now.
The search modal showed an input and the first line of the first group. The
suggestion list is absolutely positioned, which is right everywhere else -- a
list that reflows the page while you type is unusable -- but in a modal it fails
twice: an absolute list adds no height, so the panel sized itself to the search
box alone at 114px, and the panel's own `overflow: auto` then clipped the list
at that edge. In the modal the list sits in flow; the inverse is asserted so
the rule cannot leak to the pages where overlaying is correct.
Two of the new tests were wrong first and reverting the fix left them green:
they asserted hand-written markup carrying the classes I expected the components
to have, rather than the real SearchIconButton and ShareButton. They use the
real components now. Every fix was then planted against: 5 red for the More
class, 2 for the search class, 2 for the corner hit area, 1 for the observer,
2 for the modal.
1115 jest / 62 suites, 196 in ui-layout.cy.js, clean npm run build.
Confirmed live: share and search both pointer at 54.4px, More white on the bar
colour with a transparent face, and the modal's list in flow and unclipped.
Three faults in the bar, all reproduced by measurement before being fixed.
The indicators sat low. The slot carried `marginTop: 0.8em`, a nudge left over
from Semantic's menu; the corner centres its children, and a top margin is part
of the margin box being centred, so it applied as a ~6px downward shift. It
read as an error on the hotspot and the theme picker but not on share or search,
which is why it survived: an IconButton is a square ActionIcon that centres its
glyph exactly, while a bare-icon anchor sits high inside a line box that
reserves descender space for text that is not there. The nudge cancelled that
out on one shape and was pure error on the other. Both are laid out now --
flex, centred, no nudge -- and the anchors get `display: flex` so they hug their
glyph instead of a text line.
Help and Admin highlighted only a box around their text while Videos and
Statistics highlighted the full height. Same class, same rules, different
parent: the bar stretches its children, but the corner is a nested flex
container that centres its own, so a link inside it was sized to its content.
The hover background is painted on the link box, so that box IS the affordance.
The bar broke onto a second line at certain widths. Two measurement errors that
only overlap in a narrow band, which is why it appeared while resizing rather
than always. useOverflowNav measured the WRAPPER's offsetWidth and subtracted
only the home link and the corner, missing the bar's own `padding: 0 0.25em` --
about 8px it believed it had. And the hidden "More" placeholder it measured was
a plain button with no dropdown caret, about 21px narrower than the button that
eventually rendered. The placeholder is now the same component as the real
trigger, so the two cannot drift again.
Tested in ui-layout.cy.js against the real <DesktopNav/>, which takes its
colours, home link and indicators as props and so needs none of NavBar's polling
hooks. Indicator centres are measured against the bar's centre rather than each
other, because three things can be equally and consistently wrong and were. The
wrap case sweeps 1180px down to 640px in 6px steps -- a spot check steps over a
band that narrow. All three failed first: share 3.4px high, Help 24.8px against
a 54.4px bar, and two rows at 1156px.
Confirmed on the running app: every indicator at 0.0px from the bar's centre,
Help and Admin at the full 54.4px, and no wrap anywhere from 1500px to 780px.
1115 jest / 62 suites, 182 in ui-layout.cy.js, clean npm run build.
Measuring the foreground against the bar is worth nothing if the icons ignore
it, and two of them did -- the search glyph and the hamburger came out blue on
every bar in every theme while the rest of the bar was correct.
Neither inherits. An anchor takes `a {color: var(--blue)}` from tokens.css,
which outranks an inherited value however the bar sets it; the search glyph is
an anchor. A Mantine ActionIcon paints `--ai-color`, its own themed blue, and
Mantine writes that variable INLINE on the element, so a stylesheet declaring it
loses every time -- the painted property has to be set instead. The status
icons that link to /admin are anchors too, and only looked right because they
carry an inline colour of their own, which still wins and is meant to.
The test that claimed to cover this read `querySelector('...svg')`: one element,
the first, which was a plain inheriting Icon. It asserted every icon and
measured the only one that was never broken. It now reads querySelectorAll,
asserts the count, and checks all four -- and reddens in all four themes with
the rule removed, naming --blue as the value it found.
The gallery sample was wrong in the same direction: it used an IconButton for
the search icon, so it showed the ActionIcon fault twice and hid the anchor
fault entirely. It now carries all three shapes the real bar puts in that
corner.
1115 jest / 62 suites, 177 in ui-layout.cy.js, clean npm run build.
The bar's background is the one surface a user picks -- twelve colour names,
which each theme resolves to twelve of its own colours. Forty-eight
backgrounds, and the links and status icons were drawn on all of them in a
single token, `--btn-text`, which is near-black in three of the four themes.
Night's `--brown` is #451212. A near-black glyph on it is 1.33:1. Nine of
night's twelve colours and seven of amber's sat below 4.5:1, and twelve of the
forty-eight below 3:1 -- icons the same colour as the bar behind them.
So the foreground is measured against the background the theme actually
resolved, choosing between that theme's own `--btn-text`, `--black` and
`--white`. Its own, not literal ones: a white pixel in night mode undoes the
dark adaptation the theme exists to protect, so night's "white" is #ff8a8a.
Measuring at runtime rather than shipping an `--on-red` token per colour also
means the custom YAML themes still ahead get this for free.
Nothing is below 3:1 any more and the worst case is 3.27:1, up from 1.33:1.
No combination is worse than it was.
Ten of the forty-eight are still under 4.5:1 and no foreground will lift them:
a monochrome theme resolves all twelve names onto one ramp, and a mid-tone of a
hue cannot carry text of that same hue. That shortfall is in the palette, so
/theme-sample now draws all twelve bars with the measured ratio printed beside
each one, calling out the ten -- it is a decision to make while looking at them.
The WCAG primitives move to themes/contrast so theme code can measure a colour
without importing Common.js, which pulls in half the component library.
Common.js forwards `contrastRatio` with a delegating function rather than a bare
re-export: six specs mock it with `{...jest.requireActual('./Common')}`, the
spread invokes every getter, and those spreads run re-entrantly while the module
is still evaluating -- a re-export getter fires before its import binding exists
and takes the whole suite down.
Tested: navColors.test.js measures all forty-eight against the palette parsed
out of tokens.css, and holds Nav.js to the call by source since neither bar is
reachable from a test that could measure it. ui-layout.cy.js measures the
painted result in a real browser in all four themes and holds it against the
number the component reports. Reverting to the fixed foreground reddens four
jest cases and three cypress ones.
1115 jest / 62 suites, 177 in ui-layout.cy.js, clean npm run build.
Both comments were right, and the second named a real blind spot.
The e2e iterated a hardcoded theme list while the unit suite iterated
`themeNames`, so a fifth theme would have got mapping coverage for free
and no cold start. It imports `themeNames` and `themeSessionKey` now.
The sprite was invisible to it. A wrong sprite name 404s the icons and
MapLibre carries on, so the canvas exists and the suite passes -- exactly
the case the review described. The spec now intercepts
`/map-assets/sprites/**` and asserts the requested set is `mapSprite()`.
Planted it by collapsing the sprite back into the flavor: night and amber
get PAST the canvas assertion and fail on the sprite, which is the point.
The rebuild branch cannot be reached from a browser at all. MapViewer
builds a style twice -- at init, and in an effect keyed on
`[theme, mapReady, scaleUnit]` -- but the theme picker lives on Settings
and in the gallery, never in the nav, so there is no way to change the
theme with /map open; navigating to Settings unmounts the viewer. A
Cypress case that switches themes would have nothing to click.
So that branch is guarded in the source instead: both `buildStyle` calls
must pass `mapFlavor(theme)` and `mapSprite(theme)`, and none may pass a
bare `theme`. Crude, and the honest alternative to a browser test that
cannot reach the branch it claims to cover. Planted by breaking ONLY the
rebuild call: the source guards go red and the e2e stays green, which is
the whole argument for keeping it.
The call-site scan counts parens rather than matching a regex. The
arguments are themselves calls, so anything non-greedy stops at
`mapFlavor(theme)` and reports half an argument list as the whole of it --
which is how the first version of this test failed while the code was
correct.
1098 jest / 61 suites, 4 e2e themes, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Roland asked why the red overlay sits on the DARK basemap rather than
greyscale or black. Measuring it, black is the better answer and the
reason is not brightness:
flavor distinct colours hued earth luminance
dark 19 4 0.014
black 13 0 0.007
Both media filters are the same pure luminance projection --
`0.2126 0.7152 0.0722` -- so they keep brightness and throw hue away.
`black` is already achromatic, so filtering it is a hue rotation and
nothing else: all thirteen greys were authored as a monochrome hierarchy
and every one arrives intact. `dark` has more colours, but four of them
are hued (water, parks, up to 25 chroma) and those distinctions do not
survive at all -- the features land at whatever brightness their hue
happened to carry rather than one anybody chose. Black also emits half
the light on the earth fill, which is the point of a night-vision theme.
`grayscale` is not an option despite the name: it is a LIGHT theme (earth
L0.604), and a luminance filter turns a light map into a bright red one.
What made black look impossible in the first commit was the sprite, and
that was my mistake: `sprite` and the layer flavor are separate style
properties that merely shared one variable. We ship `light` and `dark`
sprite sets, and a `black` basemap with `dark` icons is an ordinary style.
They are now separate arguments, with `mapSprite()` beside `mapFlavor()`.
Fixed in passing: the contour labels branched on `flavor === "dark"` and
would have taken the LIGHT branch for `black` -- dark brown text on a
black map. Now branches on `light`, so every dark flavor gets the pale
label.
The new test is the one worth having: the monochrome themes' flavor must
paint with greys only, paired with an assertion that `dark` is NOT
achromatic. Without that pair the first would pass on any flavor at all
and prove nothing about the choice.
1096 jest / 61 suites, 4 e2e themes, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MapViewer handed protomaps-themes-base the WROLPi theme name as its
basemap "flavor". That worked while the only themes were `light` and
`dark`, and broke the day night and amber arrived: protomaps looks the
flavor up in a record and dereferences the result without checking, so an
unknown name is not a fallback but
TypeError: Cannot read properties of undefined (reading 'background')
at nolabels_layers (base_layers.ts:18)
thrown before the first tile. MapLibre never constructed, so /map
rendered nothing in two of the four themes.
`mapFlavor()` in themes/names.ts maps a theme to one of the two flavors we
can actually serve. Only `light` and `dark`: the flavor is interpolated
into `/map-assets/sprites/<flavor>` too, and those are the two sprite sets
we ship, so protomaps' `black` and `grayscale` would load a style and then
find no icons. Night and amber take `dark` and let the media filter tint
the canvas -- a filter shifts hue, so handing them `light` would give a
red or amber slab, which is the opposite of the point.
Two layers of test, because they cover different halves:
- map-flavor.test.js checks every theme against the REAL protomaps
(calling layers() and requiring it not to throw) and against the
sprites directory on disk, rather than a list of valid names copied
into the test, which is what would have passed here in the first
place. It fails when a fifth theme is added without a mapping.
- map-themes.cy.js drives the actual page in all four themes and waits
for the MapLibre canvas. The unit test cannot see whether MapViewer
USES the mapping, which is the half that was broken. Verified against
the planted regression: night and amber fail with no canvas, light and
dark still pass.
Not a bug: the 404 on /blobs/map-overview.pmtiles in the same trace. That
is a HEAD probe for an optional planet overview, gated on `resp.ok`, and
the blob is absent in a dev checkout. The console line is unavoidable.
1093 jest / 61 suites, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It sat hard against the left edge of its container despite three call
sites wrapping it in `<center>` or `text-align: center`.
Mantine builds a Pagination as a BLOCK root -- full width, so those
wrappers had nothing to centre -- holding a flex Group that carries the
controls and lays them out at `flex-start`. So `justify-content` on the
root does nothing at all; it has to reach the Group.
Setting `--group-justify` on the root does not work either, which cost a
detour: Group defaults that prop and writes the variable INLINE on its own
element, where an inherited value cannot reach it. The property itself is
fair game, since Mantine only ever reads the variable from a hashed class,
so `.wrolpi-pagination .mantine-Group-root { justify-content: center }` at
(0,2,0) is what lands.
The three wrappers are now plain divs keeping their margin. `<center>` is
a deprecated element that was doing nothing here.
Two tests: the gap either side is equal -- measured, not read off
`justify-content` -- with an assertion that the container really is wider
than the strip, since otherwise the equality holds trivially at 0 and 0.
And an inverse: at 240px nothing hangs off the LEFT edge. That one is the
risk centring introduces -- overflow in a flex-start row spills right,
where it can be scrolled to, but centred it spills both ways and the first
page becomes unreachable. It passed before this change and must keep
passing after.
Verified red first (0px left against 230px right), and the wrong-element
fix -- centring the root rather than the Group -- reddens it again.
1080 jest, 160 in ui-layout.cy.js, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The dashboard threw on arrival from any other page:
ReferenceError: Cannot access 'useCalculators' before initialization
at Module.useCalculators
at DashboardCalculators
`Calculators.js` exports `useCalculators` as a `const` and imports the ten
calculators it renders. Five of those reached back up to `Apps.js` for
`ColoredInput`, and `Apps.js` imports `CalculatorsPage` from
`Calculators.js` -- so the hub was in a cycle with its own leaves:
Calculators.js -> calculators/ElectricalCalculators.js
-> Apps.js -> Calculators.js
Webpack compiles a `const` export to a live getter, and a getter read
before the module body reaches the declaration THROWS rather than
returning undefined. That is the whole mechanism behind this particular
error, and it names the const it could not reach.
`ColoredInput` is a text field with a Label welded to one edge -- the
calculators' unit markers. It has no business in the module that ROUTES
to the calculators, so it moved to `components/ui/Inputs.tsx`. Nothing in
`components/ui` imports from `components/`, so a control kept there cannot
close a loop like this again. Gallery entry added, per the standing rule.
`src/import-cycles.test.js` is the guard: a small import-graph walker,
scoped to hubs that export a `const` into their own subtree. It fails
with the cycle printed, and it self-checks against a known cycle so it
cannot pass by finding nothing. Verified red with the cycle planted back.
HONEST LIMIT: the guard is static because I could not reproduce the
RUNTIME error in a test. TDZ needs a module to be mid-evaluation when the
getter is read, and by the time any spec body runs every module has
finished; babel also papers over it, handing back undefined where webpack
throws. I tried an e2e that navigates to the dashboard and collects
window errors -- it passes with the cycle present, so it would have been a
test that cannot fail for the reason it claims, and I deleted it rather
than ship it. A react-refresh trigger did not reproduce it either. What
is checkable, and what is genuinely the defect, is the cycle.
1080 jest / 60 suites, 158 in ui-layout.cy.js, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three real defects from the PR review, each reproduced before it was fixed.
The tag mark and a video's duration were pinned to the poster BAND, which
is the full width of the card, rather than to the painted image. Once the
height cap landed the two stopped being the same box: measured, the mark
sat 39px clear of a book cover, 56px clear of a small poster and 60px
clear of a vertical video, and the duration 55px clear. It went unnoticed
because on a 16:9 poster the image fills the band and the two pin to the
same place -- so the tests cover the height-bound ratios, and assert the
letterbox gap is really there before measuring into it.
CardPoster now centres a frame that shrink-wraps the image, and the frame
is what corner chrome is positioned against. VideoCard passes its
duration through a new `overlay` prop rather than wrapping CardPoster in a
box of its own.
The mark also went back INSIDE the link. Splitting it out made the
tagged corner a dead spot on an otherwise clickable poster.
CardLink and ExternalCardLink wrote `className='...' {...props}`, so a
caller's className replaced the pair instead of adding to it. Every
archive title passes `card-title-ellipsis`, so every archive title lost
`card-link` -- the one card type this PR migrates for layout was the one
missing the title treatment. Both compose now.
On the fourth comment, the breadth of the ActionIcon remap: it is
deliberate and the numbers are small. 59 IconButton call sites, 52 of
them at the default size, 7 at `xs` (one in Flasher, three in the
inventory schema editor). The one library control that stands beside an
input rather than a button is SearchBox's clear, and the remap is exactly
what that scale is for -- it now matches its field to the pixel, where
before it was 28px against a 36px input. Guarded by a test that fails at
42 vs 36 if the default is reverted.
1078 jest, 158 in ui-layout.cy.js, clean build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Details/Open pair on every archive card came out 36px beside 28px.
Mantine gives ActionIcon a size scale unrelated to Button's, and defaults
the two differently:
size xs sm md lg xl default
Button 30 36 42 50 60 sm (36)
ActionIcon 18 22 28 34 44 md (28)
So the two never matched, at any size, and every toolbar mixing them was
ragged -- the archive card is just where it shows most.
Mantine already ships the aligned scale as `--ai-size-input-*`, for an
ActionIcon standing beside an Input; those five values are identical to
`--button-height-*`. ui.css points one at the other, which fixes every
size at once including ones no call site uses yet, and IconButton now
defaults to `sm` like Button.
Both halves are needed and both are proven so: dropping just the `sm`
remap reddens the default and `sm` cases while xs/md/lg/xl stay green;
reverting just the default reddens the default case alone, at 42 vs 36 --
the mismatch inverted rather than fixed.
A further test pins the direction. The pair could also be squared up by
cutting the labelled button down to 28px, which would be the wrong fix.
Gallery gains a row of Button/IconButton pairs at all five sizes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four defects on /videos, /docs and /archives.
Titles were invisible outside light. `.card-link` carried a literal
`color: black` from before the themes existed -- about 1.1:1 on the dark,
night and amber panels. It applies to every card title and to the
channel/author/domain line beside it. The date was fine, since it takes
`--muted` from the card body, which is what made this look like a card
bug rather than a link bug. Titles now take `--text`: they are links,
but they are the card's text, not a wall of blue.
Posters were cropped, not mis-proportioned. The image carried a fixed
290x163 box; a card in the default grid is about 233px wide and Mantine's
Card sets `overflow: hidden`, so the browser painted the middle 233px of
a 290px image. The ratio was right in the layout tree and wrong on
screen. Replaced with caps on both axes -- the card's width and
`--card-poster-max-height: 200px` -- with `width`/`height` left `auto` so
the pair behaves as "contain". Bounding the width alone was tried first
and is not enough: a square thumbnail then stands as tall as the card is
wide, and a portrait book cover taller still.
The meta line was foot-anchored, so on /docs a PDF with no author had its
date shoved up to 55px below the title, at the bottom of a card that was
tall only because of its neighbour in the row. It now sits directly
under the title.
Archive cards read buttons-then-domain, because the buttons were children
and the meta was what got pushed to the foot. Card gains an `actions`
slot, rendered last and anchored to the foot, so a row lines its buttons
up however many lines each title took.
Gallery gains a poster row covering all five ratios and a row showing
meta/actions against unequal titles.
1076 jest tests, 145 in ui-layout.cy.js, clean build. Every new guard was
checked against a planted regression: dropping the height cap reddens the
square and portrait cases and leaves 16:9 green; `width: 100%` reddens
containment; restoring `color: black` reddens dark/night/amber and leaves
light green; re-anchoring the meta and swapping the slot order redden both
the jest order test and the cypress geometry tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A load reading under warning rendered marginally QUIETER than a healthy one:
an uncoloured value inherits `--text`, 4.98:1 on a night panel, and `--warning`
was 4.91:1. Amber had the same inversion, 7.43 against 8.59.
Anything that means "look at this" has to be louder than the prose around it,
and with no hue to carry the signal, louder means brighter. Both `warning` and
`danger` now clear `--text` in night and amber:
night warning #ee3434 -> #f54040 4.91 -> 5.40 (--text 4.98)
danger #ff3e3e -> #ff5757 5.71 -> 6.41
amber warning #f18806 -> #fa9f31 7.43 -> 9.05 (--text 8.59)
danger #ff9e29 -> #ffb760 9.15 -> 10.96
I said last time this would trade night's "red only" character for loudness.
Having measured it, that was overstated. Red contributes 21% of luminance, so
in night NOTHING above ~4.9:1 can be a pure hue -- `#ff0000` itself is only
4.99:1 there. `--text` is already `#e04a4a`, carrying 74 of green and blue.
The new warning carries 64, LESS than the text beside it; only danger goes
further, at 87. A pure-hue ramp above the text was never on the table.
The rule is monochrome-only, like the ordering rule it sits beside. A light
theme's text is near-black at ~14:1 and no warning colour will ever match it --
there, hue is what marks a reading as flagged.
The guard now asserts warning as well as danger, and the LoadStatistic browser
test makes the claim it previously had to document as unmet: warning is louder
than a plain reading. Planted the reported bug back in both themes, plus two
ordering breaks.
One plant of mine came back green and was wrong, not the test: I set night's
danger to `#f04a4a` expecting it to drop below warning, but that has MORE green
and blue than `#f54040`, and green is 71% of luminance -- so it was still the
brighter of the two. Re-planted with a value that is genuinely dimmer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The indeterminate test read the band's position out of a running animation and
asserted it had left the box. Two problems, and the second is the serious one:
it samples a moving target, and under `prefers-reduced-motion` the slide is
replaced by `width: 100%` with no negative margin, so the band never leaves the
box and the assertion is permanently false. Anyone with Reduce Motion turned
on -- or a CI host with it set -- gets a hard failure on a correct build.
Reproduced it rather than taking it on faith: forcing the reduced-motion branch
for the whole run fails the old form and passes the new one.
The band is pinned now, to where the animation's first keyframe puts it, and the
assertion is on the clip plus that escape. Deterministic, and true on any
machine. Added the other branch too: with motion suppressed the bar fills
instead of sliding, and a band that never moves must never leave the box.
`text-overflow: ellipsis` on the label. `nowrap` alone stopped it wrapping and
being bisected by the clip, but left a hard mid-glyph cut, and the call sites
that feed this are exactly the ones with long strings -- Upload.js and
FileBrowser.js label with a filename, Files.js with the error string.
The one-line test was close to circular: with `nowrap` applied, one line box is
almost a restatement of the rule. It now also asserts the computed `nowrap` and
`ellipsis`, and that the line is genuinely WIDER than the space it has -- without
that, a label that simply fits would satisfy it.
Dropped a dead ternary from the air-around-label test; it built a rect nothing
used and made it look as though the measurement came from somewhere it did not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things, plus an answer to why two sets of bars on the same page were
spaced differently.
The bar was 16px tall with an 11px bold label, leaving about half a pixel of air
above and below. On the Status page that is 44 of them. Now 22px with a 12px
label -- these labels carry device names and units, not just a number.
The indeterminate band escaped the bar. It slides on `margin-left` from -35% to
100%, and nothing clipped it, so the animation ran from outside the left edge to
outside the right one. `overflow: hidden` on the bar.
The CPU and RAM bars were touching while the drive-bandwidth bars on the same
page were not, and the difference was not the bars: CPU and RAM are bare
siblings inside a Panel, while each bandwidth bar sits alone in a Grid column
and takes its spacing from the Grid. `* + .wrolpi-progress` distinguishes those
two by itself -- it fires only when a bar actually follows something, so an
only-child bar in a column is untouched. A blanket margin would have doubled
the Grid's gutter, and that is asserted too.
The gallery gains a Progress section: six percentages, custom labels, no label,
indeterminate, and the four roles. Its own demo gaps were removed so what it
shows is the spacing the component really has.
MEASURED while building the gallery, and NOT fixed: the label reads 5.49:1
against the fill in light -- the brightness filter is what buys that -- but 2.35
in dark, 2.48 in night and 2.74 in amber. Against the empty track it is 5.2 to
15:1 everywhere. Reaching AA over the fill needs the label drawn twice and
clipped at the fill boundary so each half takes its own colour, and in night not
even that suffices: `--text` is only about 4:1 against pure black and a fill is
lighter than black by definition. Recorded in ui.css and in the test, which
asserts the track half only rather than picking a threshold low enough to pass.
One test was unfalsifiable and is rewritten. "Keeps a long label from widening
the bar" cannot fail: the label is `position: absolute; inset: 0` and takes no
part in its parent's width. What a long label actually does is wrap to a second
line inside a 22px bar and get cut in half by the new clip, so the test measures
line boxes now.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Six real fixes and one honest retraction.
The control is now a SIBLING of the heading inside a flex row, not a child of
it. Inside the `<h3>` it joined the heading's accessible name, so screen reader
heading navigation announced "Root CA Certificate Help". The row is what keeps
them on one line, and it is only rendered when there is something to sit beside,
so the markup for the other 46 call sites is unchanged.
`style` now lands on the wrapper. It used to reach the outer div; going through
Header put it on the inner heading, where a margin sets space INSIDE the wrapper
and only worked at all through margin collapse -- which stops the moment the
wrapper gains padding or a border. Status's "Drive Bandwidth" is the live case:
verified 16px on the block, 0 on the h2. Text properties still arrive, because
colour and text-align inherit; the `color` PROP stays on the heading.
A `<label>` only when `for_` names a field. Several call sites pass an
InfoHeader as the `label` prop of InputForm/ToggleForm, which wraps it in a
label of its own -- an unconditional one nested labels, which is invalid and
makes clicking the text ambiguous. Verified: zero `label label` on
/videos/settings, where "Video Resolutions" keeps its label and "Video File
Format" no longer has one.
The help controls carried `iconStyle: {margin: '0.5em'}`, which separated a
free-floating sibling and, inside the row, added to the gap on every side.
Zeroed; the row's gap is the spacing.
The browser test mounted a plain Button in an `after` slot rather than a real
HelpHeader, so the default icon chrome above was exactly what it could not see.
It mounts the real wrapper now. Two of my assertions were also too weak to
catch what they claimed: the gap was measured to `.wrolpi-header-after`, a flex
container whose own rect does not move when a child gains a margin, so it had to
measure the button; and the squeeze case used a title of ordinary words, which
simply wraps and never puts the row under pressure.
Renamed the suites -- "keeps the icon on its own line" read as the opposite of
the fix.
The retraction: `flex-shrink: 0` is declared but has NO test. Three attempts
could not find a width where removing it changes what is painted -- the row's
only other item is a heading, and its automatic minimum size absorbs the
pressure; the help control is an ActionIcon with a min-width it will not go
below either. The declaration stays as a statement of intent, with a comment
saying it is unproven, rather than a green test that does not discriminate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two things, and the second was a regression this migration caused.
A heading had `margin: 0 0 10px` -- no top margin at all -- so it sat flush
against whatever came before and read as part of it rather than as the start of
the next thing. On /more/statistics "Tags" touched the panel above it with a
0px gap. Now 22px above and 10px below, because a heading belongs to what
follows it.
`* + .wrolpi-header` rather than a blanket margin, for the same reason
StatisticGroup needed it: a heading that opens a Panel or a page is already
where it should be, and pushing it down just dents the top of its own container.
The help icon on every HelpHeader and InfoHeader had dropped to its own line --
"Root CA Certificate" in Settings is the clearest one. `.inline-header` set
`h1..h5 {display: inline-block}` so the heading and a sibling `<span>` shared a
row, which worked while these were a bare `<h2>` and stopped the moment they
gained a block wrapper: the `<label>`'s block child forced a break.
Fixed in the library rather than patched in App.css. `Header` takes an `after`
slot rendered inside the heading element, where the existing flex row already
handles alignment and spacing. Both wrappers pass their icon through it, the
`<label>` moves inside the heading so `for_` keeps associating the text with its
field (three call sites rely on it), and the `.inline-header` rules are deleted.
Fifteen call sites are fixed by fixing the two wrappers.
Tests: containment in jest, and the part jsdom cannot judge -- that the two
boxes actually share a line, and that the heading stays one row tall -- in a
browser. Planted both original shapes: the margin removed, a blanket margin
denting its container, and the control moved back outside the heading element.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The suite was titled "a load reading ranks itself", commented as covering the
thresholds, and cross-referenced from Common.test.js as the place the painted
result is checked. It mounted a hand-built `<Statistic color='warning'/>`.
So it proved that role tokens resolve distinctly -- which the roles suite two
blocks up already covers -- and would have stayed green with LoadStatistic
reverted to `orange`/`red`. The same shape as the column-border test in #609:
a claim that outran its measurement. It mounts the real helper at the real
thresholds now, and the reversion fails it.
The source guards are gone. They scraped function bodies out of files with
indexOf slices, covered two helpers, and never executed a branch. `loadRole`
and `healthRole` are pure exported functions instead, tested as mappings:
either side of both load thresholds, every SMART assessment, lower case (the
value comes from smartctl), and the case that matters most -- an unreadable
drive must report as unknown, never as healthy.
That is also the better answer to the jsdom problem that produced the guards.
jsdom rejects `color: var(--danger)` and drops it, so the mapping cannot be read
back off a rendered component; extracting it is the honest fix rather than
asserting on source text.
And the gallery was itself half-migrated: 15 Min. Load became `danger` while
5 Min. Load stayed `orange` -- in the one sample whose caption tells the reader
to go and check night and amber, where orange is byte-identical to --text.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sixteen call sites, chosen by reading each one rather than by grepping for a
hue. Four sub-agents judged them independently against one rule: convert only
what genuinely means success or failure; identification, category and
decoration stay hue-named.
Converted:
SMART drive health (all four branches -- PASS/WARN/FAIL/unknown)
config validity: valid / invalid / empty
"Failed to load preview"
the two "Download error" triggers
expired inventory items, desktop and mobile
the refresh phases: complete / active / not reached
a refresh Progress bar in its error state
cookie status: Unlocked / Locked
a chip-mismatch label on the flasher
CPU load thresholds (LoadStatistic)
the outcome of an API call in useAPIButton
the gallery's "Danger zone" heading and its load readings
Left alone, deliberately:
the file browser toolbar -- every action has its own colour to be told apart,
and delete already uses role='danger' (Roland's ruling)
diff add/remove in the config and inventory import previews. Adding is not a
success and removing is not a failure; in Overwrite mode the removals are
exactly what the user asked for, and painting them danger would report their
intended action as broken
seasons in DatesSelector, the uploader star and favourite heart, TagIcon,
downloader category buttons, "Recommended to Keep"
Three sites were wrong in a way worth naming. Both "Download error" triggers
guard on the same condition and render the same modal, but one was `orange` and
the other `red` -- and `orange` is the single worst choice, byte-identical to
`--text` in night, so that error button was indistinguishable from an ordinary
control. Config validity drew its valid state in `--violet`, which no user
parses as "valid". And `LoadStatistic` -- the thing users actually watch on the
Status page -- rendered its warning threshold in that same invisible orange.
Also fixed a stale comment in Videos.js that claimed no token existed for these.
Two notes on the tests:
The first LoadStatistic test I wrote rendered the component and asserted the
inline colour. jsdom REJECTS `color: var(--danger)` as an invalid declaration
and drops it, so every colour reads back as the empty string -- two of the four
assertions passed for that reason alone and would have kept passing with the
hues restored. It is a source guard now, with the painted result asserted in
the browser instead.
That browser test then found something real: an uncoloured reading inherits
`--text`, which in night is 4.98:1 against `--warning`'s 4.91:1, so a machine
under load is marginally QUIETER than one that is fine. Not fixed here. The
only way up on a dark panel is lightness, and night's danger would desaturate
from #ff3e3e to about #ff5d5d -- trading the theme's "red only" character for
loudness. That is a palette decision, so the test documents it and asserts what
does hold rather than quietly making it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
I said all four toast kinds were "the same pixel" in night. They were not.
Planting a reversion to hue names left the new distinctness test GREEN, because
in night `--blue`, `--green`, `--yellow` and `--red` are four different values
(2.29, 3.14, 4.52, 5.64 against a panel). What they are is cramped and badly
ranked, with info at 2.29:1 -- below the 3:1 floor, present and invisible.
The byte-identical pairs are real but elsewhere: `--orange` is `--text` and
`--yellow` is `--amber`, which bites a call site that reaches for those names,
not the toast mapping. The PR body has been corrected too.
So the distinctness assertion is not the one with teeth; the legibility floor
is. The monochrome toast test now measures every kind against the toast's own
surface, and the hue reversion fails it naming the number: 2.29:1.
Also from review:
`.wrolpi-message-error` still forced `border: 1.5px dashed var(--red)` while its
accent and icon had moved to roles -- nearly the same pixel in night, so no
colour test could see it. It follows `--message-color` now. Six more library
rules were naming a hue for a thing that means danger: the night danger button,
invalid form fields, invalid paths, path error text, danger panels and failed
table rows. All roles now, with a source guard that fails any rule whose
SELECTOR means severity and whose body names a hue. Focus rings and active-tab
accents deliberately keep `--blue`: those are the primary accent, not severity.
The tokens.css note claimed the brightness ramp held "in every theme" when the
tests deliberately limit it to monochrome. Narrowed, with the reason spelled
out, because the next person to read it would otherwise have "fixed" light to
match the prose -- which would mean reordering light's hues to satisfy a test.
Added the end-of-chain cases the review asked for: four toasts and four Messages
in night and amber, measured rather than inferred from variable names.
Colour reads now go through a strict `toRgb` that refuses anything not already
resolved. The reviewer's concern that `getPropertyValue('--info')` returns an
unresolved `var(--blue)` does not hold -- custom properties are substituted at
computed-value time and it returns `#20629c` -- but feeding an unresolved value
to a luminance calculation yields NaN, and `expect(NaN).to.not.equal(x)` passes.
Worth refusing loudly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A component now asks for what a colour MEANS -- `danger` -- and the theme
decides how that looks. Five roles: neutral, info, success, warning, danger.
The names are the ones already in the tree. `--primary/--success/--warning/
--danger` were declared in tokens.css with ZERO consumers, and `MessageKind`
was already `info|success|warning|error`; this is one vocabulary instead of
three. `error` stays a valid kind because 26 call sites write it, and `danger`
is the same thing under the token's name for new code.
The token set is the easy half. Light and dark spend a hue per role. Night is
red and nothing else and amber is amber and nothing else, and there a role has
to be a step on a BRIGHTNESS ramp -- which is why this was worth doing:
night --orange is byte-identical to --text
--yellow is byte-identical to --amber
amber the same collisions, one hue over
A call site picking between hue names in those themes is picking between
synonyms. That is why all four toast kinds were the same pixel in night, and
why an error and an informational message were indistinguishable.
Both ramps are built rather than copied: every role clears 3:1 on the panel
(neutral is allowed lower -- for pending and disabled, dim IS the signal),
severity is strictly increasing in contrast, and danger reaches that theme's
own --text brightness so the loudest role is never quieter than prose. Amber
needed its own scale, not night's: its --text is 8.6:1 where night's is 5.0:1,
so night's ramp would have left every role dimmer than ordinary text.
Fixes in passing: night's info was 2.29:1, under the 3:1 floor. And Status
loses its three `html[data-theme="night"]` overrides entirely -- it was the one
component already encoding severity by brightness by hand, and the roles are
that generalised.
Roles are registered as Mantine colors too, so `color='danger'` works anywhere
`color='red'` does.
`isMonochromeTheme` is a new predicate in themes/names. It is the same set as
`explicitOnlyThemes` today and deliberately separate: one is about how a theme
is chosen, the other about what a theme has to work with.
Scope: tokens plus the library. The ~24 app-level `color='...'` call sites are
a follow-up -- they need a judgement per site, and two of them already disagree
(Downloads.js colours the same "Download error" label `orange` on one line and
`red` on another). The 22 `violet` uses are not semantic at all and stay hues.
Tests: the ramp claims are asserted per theme in a browser, and the ordering
and danger-vs-text claims run ONLY for the monochrome themes -- in light, blue
is darker than green on white, so a brightness ramp there would fail a design
that is perfectly fine. Every guard checked red against a planted regression,
including the original bug (warning and danger collapsed to one value in night)
and night's info back at its old 2.29:1.
The roles were folded into each theme's own block rather than kept in a
standalone one, so the existing "same tokens in every theme" and "only red hues
in night" guards cover them for free.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The jest column-border test asserted the TABLE lacks `data-with-column-border`.
Mantine puts that marker on the cells, never on the table, so the expectation
held whether column borders were on or off. It now looks for the marker
anywhere in the tree.
I did plant a regression for this one -- and ran it against cypress only, where
a different test caught it. The plant was right and the suite was wrong, which
is a new way to get a false green and worth naming: run every suite that claims
the behaviour, not the one that happens to be open.
The header-surface test fell back to `getComputedStyle(documentElement)
.backgroundColor` for an unstriped row. `body` carries the page colour and the
root element carries none, so that is `rgba(0, 0, 0, 0)` and any opaque header
passed. It now compares against the `--bg` token, which is what actually shows
through an unstriped row, and additionally asserts the body really is striped
so both kinds are covered. Planted the exact case the old form could not see
-- a header painted `--bg` -- and it goes red in all four themes.
The file-row fixture rendered a 16px icon; the app renders 24. A file row
calls `<FileIcon size={null}/>`, and a null size falls past Icon's 'small'
default to Tabler's 24 -- the harder centring case, and the one the CSS comment
describes. Added the two-glyph row as well, since a folder that is also ignored
draws two icons before its name and those touched each other too.
The header-rule-width assertion now runs per theme with the rest of the suite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three things the file browser made obvious.
The header was not a surface. Mantine gives thead no background at all, so
the header painted whatever was behind the table -- which is exactly what an
unstriped body row paints. Against a striped body it read as one more stripe,
and bold type was the only thing distinguishing it. It now carries `--head`,
the token that already means "recessed surface", with a full-strength 2px rule
under it: the header/body division is the one line in a table that carries
meaning, so it is the one allowed to be loud.
Column borders are gone. A line around every cell is a lot of ink to repeat
what the column headings already say, and it was half of why the header
disappeared -- a bordered header cell looks like a cell in a grid.
Row rules were `--border`, the same weight as the outline around the table, so
a long table read as a stack of boxes. They now use `--table-line`, a new
token per theme sitting between the surface and `--border`. The table outline
is not a row rule and keeps `--border`; Mantine draws both from
`--table-border-color`, so that had to be restated.
In the file browser an icon and a filename are inline siblings in one cell. An
inline SVG sits on the text baseline, so a 24px glyph beside 13px text hung
above it -- the icon looked centred in the row and the name looked like it was
resting on the icon's floor. `vertical-align: middle` centres it, and the
margin is a gap that was never there at all: the folder icon touched the first
letter of its own name.
Cypress now loads App.css, as the app does. Without it a spec covering the
file browser rows measures a component the app never renders.
One jest test and eleven browser tests, each checked red against a planted
regression. Two notes for the next person:
- `html .mantine-Table-table` is specificity, not decoration. Mantine
declares --table-border-color on its own hashed class, which ties with
`.mantine-Table-table` and wins on source order.
- the "quieter than the outline" test measures both lines against `--panel`.
Nothing paints <html> under a mounted component, so measuring against the
root background compares them to black, which ranks the *paler* line as the
louder one -- the assertion passed backwards until it was pointed at the
surface the rules actually sit on.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The calculators page had seven "?" glyphs in a row -- `cogs`, `tint`, `food`,
`signal`, `thermometer`, `car`, `th large` -- and `arrow left` was unmapped
while `arrow down`, `right` and `up` were all there. Also `tags`, `comments`,
`chevron down`, and `closed captioning outline`.
An unmapped name is not subtle: it renders IconHelpCircle and logs a console
error. It shipped anyway, because nothing failed on it.
Three tests already guarded this and all three missed it. They cover the
theme picker's choices, the names the mimetype helpers can return, and the
map's own integrity -- none of them looks at what call sites write. The new
guard walks src/ and checks every name it finds, in each of the four
spellings, each of which was hiding at least one of these:
<Icon name='x'/> and icon='x' the plain JSX prop
{icon: 'x'} a data table; how the calculators declare theirs
icon={active ? 'tags' : 'tag'} a ternary, where `tags` was unmapped
name={s === 'descending' ? ...} a comparison operand, which is NOT a name
The last one is why the extraction strips comparison operands first: the sort
arrow in DataTable tests a direction, and reading 'descending' as an icon name
would be a false positive that trains everyone to ignore this test.
Verified by planting each spelling in the file it was found in, and by
reverting the map additions -- the guard reports them. Also swept thirteen
routes in a real browser with console.error hooked: no icon errors left.
Drops `taggedImageLabel`, a Semantic Label prop bag with no consumers, whose
`corner: 'left'` was never an icon name at all.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The "separates the skeleton from the panel" cases could not fail. A Skeleton
is three layers: the element paints nothing, ::before paints
--mantine-color-body (`--bg`) at z-index 10, and ::after paints the bar the
user actually sees (`--head` in light, `--border` in dark) at z-index 11, on
top. `paintedBackground` walked outward from the element and returned the
first paint, which is ::before -- so all four cases compared the page
background to the panel. Those differ by design in every theme, so the bars
could have collapsed into the panel entirely and every assertion stayed green.
My planted regression did not catch it because the plant was broader than the
claim: it forced all three layers to the panel colour, so the test went red
for a reason the fix did not depend on. The plant now sets only ::after, and
a second plant sets only ::before and must stay GREEN.
The layer order is now the caller's argument, since "the background" is
ambiguous once pseudo-elements are involved and guessing makes a test vacuous
rather than wrong.
Also from review:
The disc on a filled button was pinned to `--blue` at the call site, but WROL
mode disables that button and Mantine repaints it `--mantine-color-disabled`
-- a blue chip on a grey button, the original hole inverted. The surface now
comes from the cascade (`--button-bg`, and the disabled colour for any
variant), so the call site says nothing at all and cannot be wrong about a
state it does not control. Keying on `[data-variant="filled"]` alone matched
none of our buttons: Mantine omits the attribute when a call site names a
colour but no variant, which is how every filled button here is written.
The Checkbox behaviour test asserted only that a handler fired, against a box
held at `checked={false}` that could never change. It is now uncontrolled and
asserts the box is checked, plus a second test that the handler sees the new
state -- read inside the handler, because `currentTarget` is null by the time
a mock is inspected.
The empty-caption test counted every div in the container; it counts the
loader's siblings now. Two comments corrected: Pill emits no `--pill-radius`
at all and its own stylesheet falls back to `1000rem`, and the nav bar no
longer relies on the default surface.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Closes the tail of the library: `Loader`, `Loading`, `Placeholder` and
`Checkbox` had no test of their own, and `IconStack`, `MediaFilterToggle`,
`MultiSelect` and `NumberInput` were not in the gallery, which the project
rule says every component must be.
Putting them in the gallery is what found the rest of this.
An IconStack's corner glyph paints a disc of the surface behind itself so
the two sets of strokes do not cross, and that surface was hardcoded to the
page background. It is right in exactly one of the three places a stack
appears. The nav bar showed a white disc on the red bar, and the file
browser's "New Folder" button showed one punched through the blue fill. It
is now `--icon-stack-bg`, defaulting to the page: the file browser passes
the button's fill, and the nav bar sets it on the <nav> beside the colour it
already writes there, so it inherits -- the bar's colour is a user setting
and cannot be named by a token.
A MultiSelect's chosen options are Mantine Pills, and Pill is the one
component that ignores the radius theme: it writes `--pill-radius: rem(1000)`
onto the element, which zeroing `--mantine-radius-xl` cannot reach. They
were lozenges on a page of square boxes.
Twelve jest tests and sixteen browser tests. The browser half covers what
jsdom cannot judge: that a Skeleton is a different colour from the panel it
covers in all four themes (its greys are remapped to our tokens, and neither
`--border` nor `--bg` was picked with a panel behind it), that the loader
colour resolves through the token, and that the corner disc matches its
surface. Every one was checked red against a planted regression first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
All five points were right.
* The gallery's Toasts copy still read "Bottom right" after the container
moved. Anyone using that page as a visual checklist would have looked in
the wrong corner and concluded the change had not landed.
* Nothing observed ThemeProvider's own wiring. Both suites mount their own
`<Notifications position='top-right' limit={5}/>`, so moving the container
back, or dropping it, would have failed neither -- while the comments
claimed "container missing while call sites still fire" as the failure
already shipped once. Three tests in ThemeProvider.test.js now raise a
real toast through the provider and assert it appears, and where.
Asserted through a toast rather than by querying for a container: Mantine
renders an empty container for every position it supports, so the obvious
selector returns `top-center` no matter how the provider is configured.
That is what the first version of this test did, and it failed for that
reason rather than the intended one.
The five-at-once test is honest about what it covers: Mantine's own
default limit is also 5, so it does not prove the prop is there. It
catches the limit being raised.
* The default duration was untested. Sleeping 150ms and finding the toast
still up rules out "vanishes next tick" and nothing else -- it passes for
a 200ms default, for `false`, and for Mantine's own 4000ms. Read the
deadline back off Mantine's store instead: 5000 when unset, the caller's
number when given, `false` for 0.
* Space activates a followable toast in `toast.ts` and only Enter was
covered, so dropping that branch stayed green.
* Colour assertions used `toContain('red')`, which any declaration
containing those three letters satisfies. They match the whole custom
property now.
Planted four regressions to check the new tests: position, limit, the
5000ms default, and the Space branch. Three went red; the limit one did
not, for the reason recorded above.
The title contrast was verified by hand and by nothing else. jsdom cannot
check it: it resolves no `var()`, so the title's colour there is the literal
string `var(--mantine-color-white)` and every contrast assertion passes.
Six browser tests now cover it -- title and description at WCAG AA in each
of the four themes, the title staying heavier than the message where night
and amber drop its muting, and the toast taking `--panel` for its surface.
The three that can fail were checked against the fix removed: 1.13:1 in
dark, night and amber. Light passes either way, correctly, because
Mantine's light-scheme title uses `--mantine-color-black`, which the bridge
maps to `--text`.
Getting there took three corrections, all of them mine:
* `cy.mountUI` never set `forceColorScheme`, so every theme rendered
against Mantine's LIGHT scheme. Mantine keys its own rules on
data-mantine-color-scheme, and ThemeProvider sets it from the theme --
night and amber ride on dark. Any per-theme test could therefore pass on
a page that was broken in the app. This is the harness the tag contrast
tests use too.
* The support file never imported `@mantine/notifications/styles.css`,
which App.js does, so a Notification rendered unstyled and had no
surface or title colour of Mantine's to be wrong about.
* The spec's own helper mounted a second time to raise the toast, which
reset the theme to the default. All four per-theme cases ran in light.
For the record, the chain the fix breaks:
`.m_3feedf16` (the title) in dark scheme is `color: var(--mantine-color-white)`,
the bridge aliases that to `--btn-text`, and `--btn-text` is the text drawn
on a filled button -- near-black in dark, night and amber. Mantine writes
it through `:where(...)`, which has zero specificity, so a single-class
override plus `html` outranks it.
No, it did not still work. Semantic's toast took an `onClick` in its
options and made the whole toast activate it. The migrated helper
destructured four keys and dropped the rest, silently, so every toast that
carried one became a dead toast.
`Events.js` still passes one -- it did before the migration and was never
changed -- for the three events that arrive with a URL:
* `user_notify_message`, a page shared from the browser extension
* `upload_archive`
* `screenshot_generated`
The first renders the description "Click here to view the shared page",
which it was not. Nothing threw and nothing looked wrong; the toast
simply stopped being a way to reach the thing it was announcing.
`onClick` is passed through again, and a toast carrying one gets a pointer
cursor so it looks like what it is. Clicks on the dismiss button do not
follow it -- the button is inside the toast, so its click reaches the root,
and closing a notification is not the same as following it.
It is also reachable from the keyboard now, which it never was: WROLPi runs
on devices with a keyboard and no mouse, and a toast only a pointer can
follow is a feature half the deployments cannot use. No `role`, because a
`button` or `link` role may not contain interactive content and the dismiss
button is in there.
Mantine also leaves that dismiss button unnamed, so a screen reader read it
as "button". It has a label now, which is how the test for the
dismiss-does-not-follow case can find it.
Five tests, all red first. The gallery gets a Clickable button; following
the toast raises a second one, so it is obvious whether the handler ran.
The title was unreadable in dark, night and amber.
Mantine paints a dark-scheme notification title with `--mantine-color-white`,
and the bridge aliases that to `--btn-text` -- deliberately, because it is
the text drawn on a filled button, near-black in those three themes. So
the title came out rgb(28, 31, 33) on a rgb(38, 41, 43) surface: about
1.1:1, present and invisible. Fixing the alias is not an option, it is
correct for the buttons it exists for, so notifications now take their
surface, border and text from our tokens instead. Measured after: 14.9,
11.9, 5.0 and 8.6 to one.
The description follows the same route, and night and amber drop its
muting. `--muted` on a panel is 2.0:1 in night and 3.1:1 in amber -- the
description is the message itself, so those two let the title's weight
carry the hierarchy instead. (`--muted` being that dim in night is not
only a toast problem; statistic labels and inactive tabs use it too. Left
alone here.)
Position moves from bottom right to top right. Bottom right put toasts
over the file browser's sticky footer and a video's player controls, which
are the two places a background task is most likely to report while the
user is doing something else.
Gallery gets a Toasts section: one button per type, one that stacks a
numbered toast per press, one that fills the container to its limit of
five, one that never expires, one with no title, one with text long enough
to wrap, and clear-all. A toast is the one component that cannot be seen
by loading a page, so it needs buttons rather than a sample.
Tests
-----
Thirteen, where there were none for thirteen call sites -- and `toast` has
already failed once app-wide, when App.js dropped Semantic's container
while seven pages still imported the old helper and every notification
silently went nowhere.
Six were verified red against planted defects (a shared `id`, which makes
Mantine replace instead of stack; one colour for every type; `autoClose`
taking the 0 literally).
The duration tests use real timers with short durations, which matters.
With fake timers the element is never removed from the DOM -- hiding a
notification runs an exit transition, and advancing the clock, even
awaited inside `act`, does not complete it. Both the assertion and its
control then read the same whatever the code does. The test for `time: 0`
passed against a planted `autoClose: 0` twice before this was rewritten:
once asserting synchronously, once with a control that could not fail
either. It now waits for a normally-expiring toast to disappear first, so
dismissal is demonstrably working before the survivor is asserted.
Both from review, and both correct.
* The tag edit preview and the Flasher's chip badges still wrote the
calculated text colour to `color`. That is the same defect the last
commit fixed on the tag chip itself: an inline declaration no stylesheet
rule can outrank, so night keeps the colour calculated for the fill it
has just discarded and a bright fill leaves black text on near-black.
The preview is the worse of the two -- it is the preview of the colour
being chosen, so it was misrepresenting what the tag would look like at
the moment the user picks it. It now shows the tag shape as well.
Fixing the first site did not fix these, and the stylesheet comment
explaining the night and amber override already named the Flasher. So
there is a source guard now: no element carrying `wrolpi-label` may set
`color` in its style object. Verified against a planted violation,
which it reports by file.
* `hexToRGBArray` rejected the shorthand `#fff`, which left the luminance
at zero -- a near-white tag was read as black and handed light text.
Reachable because tag colours are not only picked in the colour picker:
they are stored in a config, and a config is a file a user edits by
hand. Three tests were red first, including one asserting the shorthand
and the six-digit form of the same colour agree.
`right: 100%` positions against the containing block's *padding* box, and
the tag body carries a 1px border, so a square centred there sits a pixel
inside the visible left edge. The point read as set into the tag rather
than growing out of it. Nudged left by exactly that pixel, with the
margin that reserves room for it following.
Two pixels was too far: the point's edges then meet the body's left edge
short of its corners, and the difference shows as a gap on the inner side.
The geometry test that was supposed to cover this could not tell the
difference. It asserted the tip lands far to the left of the body, which
is true either way -- the un-nudged tip is only 2px further right and
still well clear. The claim is about where the point is *centred*, so it
measures that now, and was checked against the un-nudged version.
Its neighbour, which checks the left margin covers the protrusion, is
deliberately still geometry-agnostic: the margin-to-protrusion
relationship is the invariant, and the exact offset is a matter of eye.
It also now derives the protrusion from half the square's diagonal rather
than half its side, which had made it loose enough to pass against a
margin 5px short.
Found while checking tags in the gallery, and unrelated to them.
A tab is a NavLink in the app's nav bars, but a <button> on the Inventory
page and in the theme gallery. A button carries the UA's own `buttonface`
background -- rgb(239, 239, 239) in Chrome -- and only `.wrolpi-tab-active`
set a background, so every inactive tab painted that near-white block.
Invisible in light, and a bright patch in the other three; in night it is
the one thing the theme exists to prevent.
One line, and a test in all four themes.
Four things, three cosmetic and one a real legibility bug.
* Tags were square chips. They now have a pointed left edge and an
eyelet, like a tag tied to a garment -- the shape Semantic gave them,
and the reason a tag reads as a tag rather than as a small button. The
point is a square rotated behind the left edge, sized so its diagonal
equals the body height and its two edges meet the body at the corners.
Only where something is actually a tag. `Label` carries the count
badges in the Tags table too -- file, zim, channel and domain counts --
and a point on a number reads as an arrow, so the shape is behind a
`tag` prop and `NameToTagLabel` opts in.
* They were smaller than what they replaced: 11.5px text with 3px of
padding, against Semantic's 12px and ~7px. Now 12.5px and 5px, which
also keeps them a reasonable thing to tap.
* Wrapped rows of tags sat on the row above, so they carry a bottom
margin, plus a left margin for the point to occupy.
* The text colour was unreadable in night and wrong in amber.
Tags.js calculates black-or-light against the colour the user chose for
each tag, and wrote the answer to `color` inline -- a declaration no
stylesheet rule can outrank. Night turns a tag into an outline over a
near-black page, so a near-white tag kept the black text calculated for
its fill and was left legible only by its border: 1.1:1, measured. Amber
replaces every fill with its own bright orange and was painting `#dddddd`
on `#ff9500`, about 1.9:1, and a neutral grey in a theme whose whole
point is that no other hue reaches the eye.
The fix is to stop hard-coding `color` so the theme can decide: the
calculated colour goes into `--label-text`, and night and amber override
it alongside the fill they already override. There is no second contrast
function to write, which is what this looked like it needed -- once a
theme has discarded the user's colour there is nothing left to calculate
against, and the answer is just the theme's own token.
`.wrolpi-label-white` and `-black` moved to the same variable. Setting
`color` there outranked the base rule, so amber was painting `--white` on
`--text`: light orange on orange.
`contrastingColor` was also picking the worse of its two options. It
compared a brightness figure against a threshold, and the figure weighted
the gamma-encoded bytes without linearising them, so Semantic's blue
`#2185d0` got light text at 2.9:1 where dark text gives 5.3:1. Every
mid-tone blue, teal and purple a user might pick sat in that band. It
now measures the WCAG contrast ratio of both candidates and returns the
better one, which needs no threshold at all.
Tests
-----
`Tags.test.js` is new, and covers the chip nothing covered: every other
spec takes `NameToTagLabel` from `tagsContextFixture`, which stubs it as
a function returning the name. That is how a tag could be unreadable
without a single test noticing. Two of these were verified red against
the inline `color`.
`cy.contrastRatio()` measures text against the surface *actually* behind
it, walking up to the first ancestor that paints something -- a
transparent tag has no background of its own, so a naive check reads
rgba(0,0,0,0) and concludes anything is legible. Twelve cases, three
tag colours across four themes, at WCAG AA. Plus a test asserting the
old inline-`color` version still measures below 1.5:1, so the check is
provably able to fail.
The gallery had label swatches in theme colours and no user-coloured tag,
which is why none of this was visible in it. It has eleven now, spanning
the range where the black-or-light decision flips.
The group had a frame, a surface and a hairline between every cell. It
now has none of those: a plain responsive grid, transparent, so the
statistics sit on whatever they were dropped onto and take its colour --
the page on the gallery, a Panel on Apps and Status.
That also retires the problem the previous commit went two rounds on.
Ruling the cells needs a technique that survives wrapping, because
`auto-fit` settles the number of rows at paint time: a border per cell
rules columns but not rows, and a border-coloured background behind a 1px
gap rules both but paints every track no cell landed in. With no rules to
draw, neither case exists. The gap is wider across than down, since two
statistics side by side have only air between them while stacked ones
already have the label's line.
The margin above the group is conditional on having a sibling before it.
A plain `margin-top` reads correctly under the Header that precedes most
groups, but Apps opens each of its Panels with one, and there it pushed
the values down off the panel's top padding while the bottom stayed put,
leaving every panel lopsided.
Five browser tests described hairlines that no longer exist. They are
replaced by the claims that now hold -- real space between wrapped rows,
a wider column gap than row gap, transparency and no frame anywhere, and
the conditional margin -- each verified red first: against flush rows for
the spacing, against a background-carried hairline for the transparency,
and against an unconditional margin for the panel case.
Per-theme, the pair to check is no longer the hairline and the surface but
the value and the label: with nothing framing a statistic, the contrast
between those two is the only thing giving it structure.
These three exports had no test of their own. Statistic had already been
caught out once -- it relied on Semantic's `Statistic.Group` for its
spacing, so it broke silently when that was uninstalled -- and they are
on the Status, Dashboard, Apps, Docs, Videos, Archive and Channels pages.
Four defects, each with a test that goes red without the fix:
* StatisticGroup ruled between columns only, with a `border-right` on
every cell but the last. `auto-fit` wraps, so the seven statistics on
the Docs page became four rows on a phone with no rule between them,
and the cell ending each earlier row drew its border straight onto the
group's outer one, making that edge 2px on the right and 1px on the
left. The hairlines are now a 1px grid gap filled by an outline on
each cell, which rules both axes however the tracks fall.
Ruling the gaps with a border-coloured background behind the grid --
which is where this went first -- has the same reach but paints every
track no cell landed in: an odd count left the last slot a solid grey
block. An outline is drawn only where a cell is. Both of these are
guarded, because the second was introduced while fixing the first.
* A statistic that renders nothing left a padded cell and a stray
hairline mid-row. FanRPMStatistic returns null on a device with no fan
connector, which is most of them, so this was the Status page's normal
appearance. The group cannot render a child to find out, so the cell
is still emitted and `:empty` takes it out of the grid -- which is why
the cells carry no inline style for that rule to have to outrank.
* Statistic destructured five props and dropped the rest. LoadStatistic
and the four Status wrappers all end in `{...props}`, so anything
passed through a wrapper vanished with no error anywhere.
* VideosStatistics passed `style={{margin: '2em'}}` to every statistic,
Semantic-era spacing that the grid now provides. It beat the group's
own rule, being inline, and made that one page's statistics sit
differently from the six others.
CardGroup was the only component in the library with no class of its own,
which left nothing to assert against -- `container.firstChild` in jsdom
is Mantine's injected <style> element. It has one now, and takes
className/style/rest like its siblings.
The gallery grows a seventh statistic, so the group wraps at a normal
window width where the row hairlines can be seen, and a second group of
coloured readings as Status renders them.
Geometry, hairlines and per-theme token resolution are in ui-layout.cy.js
rather than jest: jsdom returns zeros from getBoundingClientRect and
never resolves a var(), so it cannot judge any of it.
Greptile's point on #592 was right and generalized further than the case it
raised. The guard compared property names only, so it passed while the published
contract disagreed with the endpoint about what those properties contain.
Three wrong types, all pre-existing, all now caught by a test:
StatusResponse.downloads was `int` while the handler has always sent the download
manager's summary object -- the spec told a generated client to expect a number
where it gets a dict. It is now DownloadsSummaryResponse, with the six fields
get_summary() actually returns.
StatusResponse.wrol_mode was `str`; wrol_mode_enabled() returns a bool.
SettingsResponse.log_level was `str` while the handler sends a Python logging
integer -- SettingsRequest.log_level already said int, and the frontend converts
it numerically through fromApiLogLevel(). settingsFixture was carrying 'info',
which that function maps to undefined, so every Settings test has rendered a blank
log-level label where production shows "Info". The fixture now carries 20. This
came from the same hand-written cypress body as cpu_percent did.
statusFixture's nested downloads was also short a field: daily_limit_reached, one
the API has always sent. /api/status returns an empty downloads object while the
database is down, which it is for much of the suite, so the endpoint cannot vouch
for its own nested shape -- get_summary() is the authority and is now compared
directly.
The type check runs against both endpoints rather than only the one the review
named; that is how log_level surfaced. Comparison is limited to properties the
spec gives a type for and the handler actually sent, since a null from an optional
field says nothing about its declared type.
Fixture values are still compared by name only: they are read from JS source
rather than executed, so their types are not reliably available. Said plainly in
the test rather than left to look like coverage.
1709 pytest, 986 jest, 46 e2e. One unrelated flake in one backend run (the known
filename-formatting tests under -nauto), clean across two further full runs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The React specs stub API responses with app/src/test-fixtures.js, and nothing
connected those to the API. They were a snapshot of whatever each endpoint
returned when someone last wrote one out by hand, and they had drifted.
The chain is now guarded in two links, because the spec was not trustworthy
either:
handler <-> OpenAPI spec <-> test-fixtures.js
What the guards found on their first run:
/api/settings publishes a spec declaring hotspot_status and throttle_status,
which moved to the Controller and which the handler had long stopped returning --
/docs was promising callers two fields the endpoint never sends -- while omitting
four it does send. settingsFixture was missing seven real fields, so any spec
intercepting that endpoint handed the app a body with seven holes in it and every
assertion about the rest still passed.
/api/status was further gone: the spec declared seven fields the handler does not
return and omitted seven it does. statusFixture was missing seventeen and
invented two -- cpu_percent and memory_percent, which no endpoint has ever
returned and no component has ever read. They came from a hand-written cypress
body and had been copied onwards from there, including by me last week.
Both response dataclasses now describe what the handlers actually return. Half
of /api/status is assembled from shared_ctx.status, which is what made it look
undeclarable, but that dict is seeded with a fixed set of keys in contexts.py and
the worker only ever updates those -- so it is declarable, and now declared.
Uncoverable fixtures are listed rather than left looking covered: domainFixture
and tagFixture stand in for endpoints whose @openapi.definition carries a
description and no response=, so the spec promises nothing about their bodies,
and fileWorkerStatusFixture has no declared shape at either end because that
context's default is null by design (useFileWorkerStatus relies on it to detect a
missing provider). Declaring a response on one of those endpoints is how its
line comes off the list.
Both links were verified by adding a field to the handler and watching them fire
in sequence: first the spec check, then -- once the schema was updated -- the
fixture check. The fixture reader itself had a bug the guards caught: its regex
excluded digits, so it reported is_rpi4 and is_rpi5 as missing from a fixture
that had them. Its own guard now covers that.
1706 pytest, 986 jest, 46 e2e.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both of Greptile's findings on #591 were real, and the first was a plain miss:
mockModule shipped with no caller, so its documented usage had never once been
executed and could not have worked. It called jest.requireActual on a path
passed in by the spec, which resolves relative to test-utils.js rather than to
the caller -- for any spec in a subdirectory the documented
'../hooks/customHooks' pointed outside src altogether. It now takes the module
the spec has already resolved, and throws on a string rather than quietly
resolving to the wrong one, which was the original failure.
It also has a caller now. FileBrowser.test.js listed six hooks in a hand-written
factory and returned only those, so every other export of customHooks was
undefined for anything it rendered -- the exact landmine the helper exists to
remove.
The second: `inverted` drove Mantine's colour scheme on its own, so asking for
night or amber through the new theme option produced a tree that reported a dark
theme while Mantine rendered its light one. Production cannot reach that
combination, and a harness that invents states the app never has is worse than
one that is merely incomplete -- what a test proves about such a tree is true of
nothing. The scheme is now derived from the theme name via isDarkTheme, and
data-theme is stamped on <html>, without which a component test cannot exercise
any token table or the night-mode treatment at all. isDark remains overridable
so a spec can still make the two disagree deliberately.
test-utils.test.js covers the harness itself, which had none. Eight of its
twelve assertions were red against the code above.
986 jest, 46 e2e, clean cache-busted build, tsc clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Specs had no shared vocabulary for the app's data or its contexts, so each one
rebuilt both. A settings object was written out by hand wherever one was needed,
twenty-odd keys at a time, and nothing held those copies to each other or to the
API. Contexts were worse: to render a consumer a spec mocked the whole context
module, which replaces every export including the providers, so each spec
reinvented the pieces it still needed. One supplies a `Media` that always
reports desktop -- quietly leaving that component's mobile branch untested -- and
one hand-writes a context as a bare `_currentValue` with no provider, working only
because useContext reads that React internal.
test-fixtures.js is now the single definition of both, shared by jest, the
Cypress component specs, and e2e intercept bodies, so the three cannot disagree
about what the API returns. Every fixture is a function taking overrides; a
shared mutable object lets one test change what the next one sees.
The drift this prevents was already real. The theme fixture supplied `i`, `s`
and `t` holding hardcoded Semantic greys for months after ThemeProvider stopped
supplying them, and ThemeContext still declared all four. So the fixture agreed
with the tests, and with nothing else: FileBrowser was reading `inverted` off the
context and pasting the resulting `undefined` into a className, which is why the
file browser's footer -- near-white #f9fafb, with a `.inverted` dark variant that
nothing could select any more -- stayed light in dark, night and amber. A white
bar pinned to the bottom of the screen in night mode costs the user exactly the
dark adaptation the theme exists to protect. It takes tokens now.
test-fixtures.test.js holds each fixture to its context's declared shape in both
directions, so a property added to one and forgotten in the other fails a test.
Two failed attempts are recorded in test-utils.js because both were instructive.
Importing Tags.js and FileWorkerStatusContext.js so the harness could supply
those providers broke eight suites: it put both into the module graph of every
spec ahead of that spec's own mocks, and components bound to a second instance of
a mocked module -- a different jest.fn() than the test had configured, so a hook
mocked to return a value returned undefined, in a file no test mentions.
Requiring them lazily fixed that and not its mirror image: useContext read a
different TagsContext than the harness had required, so the provider was ignored
and the context default won. A harness must not change what a spec imports, so
it owns only contexts/contexts.js and a spec passes any other context itself.
DomainTagging is converted off the `_currentValue` fake as proof, and now asserts
the tag name a user sees rather than a test id its own mock invented. The five
remaining specs are listed in a ratchet so the count can only fall.
974 jest, 15 browser component, 46 e2e, clean cache-busted build, tsc clean.
Fixtures are confirmed absent from the shipped bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Greptile's three findings on #590, all confirmed real before fixing, and each one
verified red against the original code afterwards.
P1, the directory fields had no accessible names. All five rendered their
visible label as a bare <label> with no htmlFor while passing no label prop, so
their inputs had a description ("/media/wrolpi/") and no name at all -- five
fields in one grid, holding similar relative paths, indistinguishable to a
screen reader. The labels now belong to the inputs, InfoPopup content and all.
This predates PathInput; the old TextInput call sites had the same gap, and
moving to a component that supports labels is what made it fixable.
P1, description and error were rendered but never referenced. aria-describedby
pointed only at the prefix, so the help text listing the variables a path
accepts, and the reason a path was rejected, were both invisible to assistive
technology. Both are now in the description, and an errored field reports
aria-invalid.
P2 was worse than reported: at `flex: none` a long prefix took the entire row
and left the input eighteen pixels wide -- not "consumes the editable area" but
a field nobody can type in. The media directory is whatever the API reports, so
its length was never ours to assume. The prefix now shrinks and ellipsises at
half the control, with the full path on `title` and in the accessible
description.
The naming fault could not have been caught where the others were. jsdom cannot
see layout, and the Settings page needs enough mocking that it had no test at
all -- which is why these five fields were uncovered when they broke. The new
e2e spec intercepts the API and lets the real page render, so it measures the
names and the geometry a user actually gets. Reverting one field to a bare
label fails it; a long prefix fails the browser spec at 18px.
962 jest, 15 browser component, 46 e2e, clean cache-busted build, tsc clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The PathInput overlap could not have been caught by jest -- jsdom computes no
layout -- so the only guard was a grep for one spelling of one mistake. This
adds the layer that can actually see it, and it found a real bug immediately.
ui-layout.cy.js mounts library components in a real browser through a new
cy.mountUI(), which supplies Mantine's provider and a stamped data-theme and
nothing else. That spartan setup is the point: these components read no
ambient state, so a spec can assert what jsdom cannot compute -- real geometry,
resolved custom properties, applied filters -- across all four themes.
It reproduces the leftSectionWidth='auto' overlap on purpose and asserts it
still overlaps, because a geometry check that has never gone red is
indistinguishable from one that cannot fail.
The bug it found: the rule resetting `filter` on leaf media inside a `.media`
wrapper scored (0,2,2) against the (0,3,1) rule it was correcting, so it lost
every time and never applied to anything. Every image inside a filtered
wrapper has been through the luminance matrix twice since that rule landed --
markedly darker than its surroundings, which is exactly what it was written to
prevent. tokens.test.js asserted only that the rule's text was present, and so
stayed green throughout; it now compares the two selectors' specificity, which
is computable without a browser and goes red on the old selector.
Three guards in ui.test.js keep the library mock-free by construction rather
than by habit: no jest.mock in its own tests, no fetch in any library file, and
no useContext outside the theme controls, whose job is to read the theme. All
three were verified red against planted violations.
959 jest tests, 14 new browser tests, clean cache-busted build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The five Special Directories fields on the Settings page were unreadable: the
media directory printed straight through the value, so Archive Directory showed
`a/media/wrolpi/hain_tag)s/%(domain)s`.
Cause: `leftSectionWidth='auto'`. Mantine turns that prop into
`--input-padding-inline-start`, and `padding-inline-start: auto` is not valid
CSS -- it resolves to zero, so the input reserved no room for the section
positioned on top of it. It fails only in CSS, only at runtime, and nothing
warns.
Fixed by expressing the field in the library instead of computing a width.
PathInput puts the prefix and the input side by side in a flex row sharing one
outline, so there is no width to get wrong and nothing to overlap -- the failure
is structurally impossible rather than merely corrected. It also sizes to any
prefix, which matters because the media directory is `/media/wrolpi` on a Pi and
something else under Docker.
Written test-first, and the tests need no mocks at all -- no context, no fetch,
no router, just the provider test-utils already supplies. That is the point:
Settings.js needs a pile of provider and API mocks, so its inputs were never
covered, which is how five broken fields shipped. The tests assert the things
that actually matter and can be checked without layout: the prefix is a sibling
rather than a child, the value never contains it, onChange reports only what was
typed, the prefix is the field's accessible description so a screen-reader user
knows what the path is relative to, and disabled reaches the input rather than
just the wrapper.
Plus a source guard, since jsdom cannot see an overlap: nothing may pass
`leftSectionWidth='auto'` or `rightSectionWidth='auto'`. It strips comments
first -- PathInput documents the mistake by name, and prose about a mistake is
not the mistake.
`semantic-ui-react`, `react-semantic-toasts-2` and `semantic-ui-offline` are
gone from package.json, the lockfile and node_modules -- 19 MB of dependencies
that nothing had imported since the migration finished.
Four things still referenced them and would have broken on uninstall. None was
caught by a build or by jest:
Four test files still ran `jest.mock('react-semantic-toasts-2', ...)` for
components that no longer use it. A jest.mock of a module that does not exist
throws, so the packages could not have come out without this.
`src/components/Download.cy.js` and `cypress/support/component.js` both
imported semantic.min.css. The support file now loads what the app loads --
index.css, the font and token stylesheets, and Mantine's.
The ratchet changes job rather than being deleted. An import of a missing module
fails loudly now, but three quieter mistakes would not: a `className="ui button"`
that styles nothing, a file reaching back through Theme.tsx, and someone
reinstalling a package to "just use one Semantic component". It asserts all
three, plus that package.json names nothing matching /semantic/i.
Two pre-existing problems in the cypress component harness surfaced while
checking the uninstall had not broken it, both fixed because that file had to be
edited anyway:
It imported `react-router-dom`, which is not installed -- this app is on
react-router v7. Dates to 5621d473, so the component suite has been
un-runnable since well before this migration.
Its mount helper supplied no MantineProvider, so every library component threw
-- the same gap test-utils.js had for jest.
The component specs now load and four pass; eleven assertions are still written
against markup from before they stopped running. Repairing those is its own
piece of work, deliberately not bundled in here. The e2e suite is unaffected:
43/43.
Videos.js has its own VideoCard, separate from the file cards in Files.js, so
restoring the accent there missed it -- archives and documents showed the edge
and videos did not.
Audited every remaining `<Card>` rather than fixing the one that was reported.
The only two without an accent are the map's place card and the loading
placeholder, and neither has a mimetype to colour, so both are correct.
Videos show blue and audio-only entries show violet, which is right rather than
inconsistent: both come from `mimetypeColor`, the same helper that colours the
file icons, so a card and its icon can never disagree.
Roland's call, and the better one: along the top the accent sat immediately
against the poster's own top border, so the two edges competed. On the bottom it
closes the card and reads as a property of the whole thing rather than a header
rule.
Two agents independently dropped it, each because our Card had no `color` prop
and each citing the other's precedent -- which is how a deliberate feature
quietly becomes a convention. Roland wanted it back.
Card takes a token colour name and draws it as a 3px edge along the top rather
than tinting the surface: surfaces stay flat per the design rules, and an edge
survives night mode without becoming a bright patch. Because it is a token, the
accent remaps per theme -- four hues in light and dark, a single one in night and
amber, which is the point of those themes.
Restored on every card that shows a file: the video, image and generic file cards
in Files.js, and the archive card. All of them take it from
`mimetypeColor(mimetype, path)`, the same helper that colours the file icons, so
a card and its icon agree.
