Files

n.siegfried 5f3141e2a3 T1.5 - F5 (interim): wizard fields stop looking disabled

INTERIM. T3.4 removes the duplicate token underneath this; the job here is only
the appearance, and no token consolidation is started.

The wizard filled its inputs with var(--bg) - which in this sheet is the PAGE
BACKGROUND, #f4f4f4 - on a #e0e0e0 border. An empty required field was
indistinguishable from a locked one, which is why people were not typing in
them. The cause is the one the review named: this sheet redeclares its own
tokens, so it never saw --cds-field: #ffffff, even though theme-light.css has
been supplying that to this page all along.

Fields now consume --cds-field, and take the same --border-strong the creator's
inputs already use, so a field looks like a field on both pages. No new value is
introduced - both tokens already existed.

That inverts a signal if left there, so it needed the other half: there was no
disabled rule at all on this page, meaning locked fields would have turned white
too. Disabled and readonly fields now take --cds-field-02, the theme's own
secondary field surface, matching .locked-field in the creator. Enabled #ffffff
against disabled #f4f4f4, verified by computed style rather than by eye.

The border is deliberately the same on both states. I first wrote
`border-color: var(--border)` on the disabled rule and could not demonstrate it
taking effect - the rule matches, is more specific than the base rule, and its
background applies, but the computed border stayed --border-strong. Rather than
ship a declaration whose effect I cannot show, it is gone: a consistent border
is what "consistent with inputs elsewhere" asks for, and the fill is what
carries the state.

Screenshot diff is limited to the wizard, but establishing that took a control
run. admin and users appeared to change too, until capturing twice with NO code
change showed they differ from themselves - the console pages render live
timestamps and are not byte-stable. login, launcher, sop, creator and field are.
Recorded in the baseline README so the next task with a "no layout change"
done-when does not chase it.

The F5 probe now also fails if enabled and disabled fields become identical,
which is the way this fix could silently go wrong.

f_items: F1-F5 FIXED, F6 untouched as wave 1 requires. browser_check 71/71.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-14 18:48:47 -05:00

5.2 KiB

Raw Blame History

Baseline — August 14, 2026

Task: T0.2 · Branch: feat/wp-suite-r2-implementation · commit before wave 1

The before images every later PR compares against, and the record of which rendering defects were confirmed present at the start.

Screenshots

14 images, <page>-<width>.png, at 390px and 1440px. The plan says 12 (6 pages × 2); there are 7 pages, so there are 14 — see file-map.md D1.

Page	390px	1440px
login	`login-390.png`	`login-1440.png`
launcher	`launcher-390.png`	`launcher-1440.png`
SOP wizard	`sop-390.png`	`sop-1440.png`
creator	`creator-390.png`	`creator-1440.png`
admin	`admin-390.png`	`admin-1440.png`
field view	`field-390.png`	`field-1440.png`
directory/users	`users-390.png`	`users-1440.png`

Regenerate, or capture the "after" half of a comparison:

python tests/baseline_shots.py                                  # -> here
python tests/baseline_shots.py --out /tmp/after --label after

390px is captured with Chrome's mobile flag set, not as a narrow desktop window. Every page declares width=device-width, so this is the layout a field tablet actually gets. The script asserts the width it asked for is the width the page saw.

Two pages are not byte-stable — do not diff them blindly

Found at T1.5. Capturing twice with no code change at all produces different bytes for admin and users at both widths. login, launcher, sop, creator and field are stable. The console pages render live timestamps, so a byte comparison of them reports a change on every run.

A task whose done-when is "no layout change at 1440px" therefore cannot use a byte diff on those two. Run the capture twice before drawing any conclusion, or compare a page that is stable. Four of the "changes" in this document's own history were this, not code.

F1–F6: all six reproduce

Measured in a browser by tests/f_items.py, not read from source. Re-run any time:

python tests/f_items.py            # all six
python tests/f_items.py F2 F5      # a subset, after one task

Each probe reports REPRODUCES, FIXED or INCONCLUSIVE — never a silent pass. The same script is the regression check for waves 1–3: an item is done when its probe flips to FIXED.

Item	Verdict	Measured	Evidence
F1	REPRODUCES	Picked "Job A" in the launcher picker: hero became `Job A`, app bar stayed `Select a project`, `wp_active_project=projA`, no reload.	`launcher-1440.png`
F2	REPRODUCES	Field view at 390px: `Sign out` occupies x 382–432 against a 390px viewport — cut in half. Bar is 424px of content in 374px, ~3 rows tall.	`field-390.png`, `launcher-390.png`
F3	REPRODUCES	SOP header with the real long name: injected chrome paints over the logo by 106×32px at 1024px and 41×32px at 1440px; `.header-left` collapses to `clientWidth 0`.	`f-evidence/F3-sop-header-*-longname.png`
F4	REPRODUCES	Standalone creator: comments drawer overlaps the header by 380×91px once open.	`creator-1440.png`
F5	REPRODUCES	5 of 5 enabled wizard inputs compute to `rgb(244,244,244)` fill with `rgb(224,224,224)` border — the `#f4f4f4`/`#e0e0e0` the review named.	`sop-1440.png`
F6	REPRODUCES	Creator is 11 cards in a single 5,017px scroll, 0 sectioning controls, 3 jump links. Review said ~4,700px; it has grown.	`creator-1440.png`

Notes that change how a fix gets verified

F1 is only visible if localStorage is not primed first. Setting both wp_active_project and wp_active_project_obj before load makes the two sources agree and hides the defect. The probe clears storage and drives the real picker.
F3 is only visible with a genuinely long project name, and it has to be long in the database — any page reached with ?project= re-pulls the project from the server and overwrites a name faked in localStorage. The probe seeds Micron EUV Cleanroom Enable 2667008 as a real project.
F3 cannot be measured by comparing .header-left to the chrome. Under the long name .header-left (flex:1; min-width:0) collapses to zero width, so that comparison reports a tidy zero gap while the chrome is painting across the logo. The probe measures against .logo, which is flex-shrink:0 and therefore the one box in the bar whose position means something. A fix that leaves .header-left collapsed has not fixed F3.
F5 must ignore genuinely disabled inputs, or the fix looks done while real fields stay grey. The probe counts only enabled, visible, non-hidden fields.

Horizontal overflow, measured at capture time

documentElement.scrollWidth against clientWidth. Recorded because four pages overflow at 390px and one also overflows at desk width, which no F item covers.

Page	390px viewport	1440px viewport
launcher	425px content	—
SOP wizard	429px content	—
creator	485px content	1551px content
field view	432px content	—
login, admin, users	fits	fits

The 1440px creator overflow is logged as BL-001. The 390px ones are F2 and its neighbourhood, resolved properly by B1 in wave 2.

5.2 KiB Raw Blame History Unescape Escape