You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"Use my location" saves, but the setup banner still says 'Set your location' and the boxes stay red until Save #383
Customer-visible effect: after "Use my location" saves the location, the setup banner still says "1. Set your location", and the Latitude/Longitude boxes stay red, until the owner presses Save. This is on a fresh unit's first setup, the one screen a new owner reads when something might be wrong. Reported by Daniel during the v16 fresh-boot acceptance, 2026-10-08.
Line refs: src/ConfigurationWebServer.cpp at 74866aa.
Cause (a second path that skips an existing fix)
At page load, if the location is empty (stNeedLoc, :307), the banner is drawn (:314-329) and both boxes get a red outline (:361). The outline is cleared only by an input event on each box (:362).
window.bpSetupDone() (:349-360) re-reads the live inputs and collapses step 1 to "DONE", or removes the banner. Its own comment (:340-348) describes this exact symptom, "still read '1. Set your location' until they refreshed", as already fixed. Its only caller is the form-save path (:176).
never calls bpSetupDone(), so the banner stays at "1. Set your location";
sets .value from script, which fires no input event, so the red outlines stay.
The main Save press then runs the form-save path, and both clear.
CLAUDE.md's when you add a second path, enumerate what the first one establishes: the form save establishes "the checklist reflects the live inputs", and the v15 auto-save never went through it.
Fix (v17, not built)
On the auto-save success, after setting the values, call window.bpSetupDone() and clear both outlines. Either dispatch input on each box, or move the outline clearing into one function that both paths call, so a third path cannot miss it.
Test: the page's existing JS checks (config-form in CI) gain a case that drives the auto-save success with a stubbed fetch('/location'), and asserts the banner's step 1 reads DONE and neither box carries the red outline. A control asserts the outline is present before the save.
Sabotage: remove the bpSetupDone() call from the success path; the test fails.
Customer-visible effect: after "Use my location" saves the location, the setup banner still says "1. Set your location", and the Latitude/Longitude boxes stay red, until the owner presses Save. This is on a fresh unit's first setup, the one screen a new owner reads when something might be wrong. Reported by Daniel during the v16 fresh-boot acceptance, 2026-10-08.
Line refs:
src/ConfigurationWebServer.cppat74866aa.Cause (a second path that skips an existing fix)
stNeedLoc, :307), the banner is drawn (:314-329) and both boxes get a red outline (:361). The outline is cleared only by aninputevent on each box (:362).window.bpSetupDone()(:349-360) re-reads the live inputs and collapses step 1 to "DONE", or removes the banner. Its own comment (:340-348) describes this exact symptom, "still read '1. Set your location' until they refreshed", as already fixed. Its only caller is the form-save path (:176).shLa.value=j.lat; shLo.value=j.lon;(:290) and shows the success message. It:bpSetupDone(), so the banner stays at "1. Set your location";.valuefrom script, which fires noinputevent, so the red outlines stay.CLAUDE.md's when you add a second path, enumerate what the first one establishes: the form save establishes "the checklist reflects the live inputs", and the v15 auto-save never went through it.
Fix (v17, not built)
window.bpSetupDone()and clear both outlines. Either dispatchinputon each box, or move the outline clearing into one function that both paths call, so a third path cannot miss it.config-formin CI) gain a case that drives the auto-save success with a stubbedfetch('/location'), and asserts the banner's step 1 reads DONE and neither box carries the red outline. A control asserts the outline is present before the save.bpSetupDone()call from the success path; the test fails.