fix(web): collapse the "Add profile" form on load like session/secret - #533
Conversation
settings.js's init-time collapse list omitted "profile-editor", so the profile-add form stayed in its server-rendered, always-visible state instead of hiding behind the "Add profile" button — and a first click then hid it instead of revealing it. Add an e2e assertion covering all three editors' initial hidden state, since none of the existing tests checked that. Fixes #532
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 8 included reviews per hour; 2 remain after this review. 📝 WalkthroughWalkthroughThe settings initialization now collapses ChangesSettings profile editor
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The settings page now initially collapses the Add profile form when JavaScript is enabled, matching the other editors, while the existing button interaction reveals it. The implementation and generated output are aligned and covered by browser regression testing. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Linked Issues checkExplanation The pull request adds "profile-editor" to the initialization collapse list and adds end-to-end coverage for the hidden initial state and click behavior. These changes satisfy the coding objectives in issue [ Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Motivation
Fixes #532.
settings.js's init-time editor-collapse list omitted"profile-editor", so the "Add profile" form rendered in itsserver-rendered, always-visible (no-JS-fallback) state instead of
collapsing behind the "Add profile" button the way "Add session" and
"Add secret" already do. First click on "Add profile" then actually
hid it (toggling
hiddenfalse -> true) instead of revealing it.Fix
One-line addition to the shared collapse-on-load list in
modules/src/settings.js. The click handler and.editor/hiddenmechanism were already generic over any
data-toggleid, so nothingelse needed to change.
User-visible effect
"Add profile" now matches "Add session"/"Add secret": collapsed by
default, expands on click. No security effect (client-side
progressive-enhancement only; the no-JS form POST path is unaffected).
Screenshots
Before (both forms collapsed, only the buttons show):
After clicking "Add profile" (form expands, session form stays collapsed):
Verified locally by assembling
settings-daemon.pyfrom this branch'sworking tree (no Nix build needed) and driving real headless Chromium
over CDP against it — clicking both "Add profile" and "Add session" and
reading back each editor's
hiddenstate.Checks run
nix build -L .#checks.aarch64-linux.module-generated-up-to-date— passnix build -L .#checks.aarch64-linux.assemble-module-escaping— passnix run .#update-golden— regeneratedtests/golden/for thesettings.jspayload change (checkedtests/native/expectedtoo;it doesn't embed this payload, nothing to regenerate there)
/code-review(medium) — one finding (stale golden snapshot), fixedbefore this push
settings-pageVM test is x86_64-only and this box is aarch64, soit could not be run natively here; live-browser verification above
covers the same behavior. CI will run it.
(
tests/e2e/settings-page.spec.ts) asserting all three editors(session/profile/secret) start hidden and open on click — none of the
existing tests checked an editor's initial hidden state, so this bug
had no regression coverage before.
No AWS/IAM/networking impact (settings-page JS only).