The RPC and Blockscout "Save" buttons in Settings now store nothing when the input no longer shows the URL that was checked. When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again. A redraw during the check puts this page's URL back in the input. Before this change, the typed URL was then stored and "Saved." appeared.
The input is compared inside the save that #684 and #694 built. A redraw after the comparison shows the stored URL.
Each refused save shows its own flash message:
A save refused because the network changed shows "The URL was not saved because the network changed."
A save refused because the input changed shows "The URL was not saved because it was changed during the check."
When both apply, the network message shows.
Judgement call: the user's own edit of the input during the check also refuses the save.
Model: opus-5-5
The RPC and Blockscout "Save" buttons in Settings now store nothing when the input no longer shows the URL that was checked. When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again. A redraw during the check puts this page's URL back in the input. Before this change, the typed URL was then stored and "Saved." appeared.
The input is compared inside the save that https://git.eeqj.de/sneak/AutistMask/pulls/684 and https://git.eeqj.de/sneak/AutistMask/pulls/694 built. A redraw after the comparison shows the stored URL.
Each refused save shows its own flash message:
- A save refused because the network changed shows "The URL was not saved because the network changed."
- A save refused because the input changed shows "The URL was not saved because it was changed during the check."
When both apply, the network message shows.
Judgement call: the user's own edit of the input during the check also refuses the save.
Model: opus-5-5
src/popup/views/settings.js, saveEndpoint(): a save refused because the field no longer shows the URL gives the user no answer. The last flash is "Testing endpoint...", which clears after two seconds. If the user edits the field during the check, the field then shows a URL that is not stored, and nothing says so. The user can believe that URL was saved. After a redraw, the typed URL disappears with no reason given. Every other outcome of "Save" has a flash message, including the network refusal from #684. Acceptable: a plain flash sentence, for example "The URL was not saved because it was changed during the check." The README bullet then says a flash message says so, as the network bullet above it does, and the new test checks that text.
src/popup/views/settings.js, saveEndpoint(): fieldChanged and "the field" in the new comment mean the text input. Two lines above, field is the stored key ("rpcUrl" or "blockscoutUrl"). So fieldChanged reads as "that key's value changed". Acceptable: inputChanged, and "the input" throughout the comment, matching the input parameter and the README.
Same comment, last sentence: "The field is compared inside the save, so a redraw after the comparison shows url from state." must be read twice, and url does not come from state. Acceptable, for example: "The save compares the input and sets url in state in one step. So a redraw after the comparison shows url."
tests/settingsEndpointSave.test.js: no test has the endpoint answer while the follow waits for the lock. That is the one order in which comparing inside the save matters. With the comparison moved before saveState(), every test passes, and in that order "Saved." appears again over the old URL. Acceptable: one more case that holds the lock while the follow and the save both wait, as tests/popupFollowsNetworkSwitch.test.js does for the network refusal.
PR body and commit message:
"The field already shows the stored URL." is false when the user's own edit refused the save: the field shows the edit.
"as the plan on the issue states" is false: the plan says no "Saved.", not no flash message.
"A refused save shows no flash message." reads two ways: the network refusal is also a refused save, and it shows one.
Acceptable: after finding 1, say which refusal shows which message.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. `src/popup/views/settings.js`, `saveEndpoint()`: a save refused because the field no longer shows the URL gives the user no answer. The last flash is "Testing endpoint...", which clears after two seconds. If the user edits the field during the check, the field then shows a URL that is not stored, and nothing says so. The user can believe that URL was saved. After a redraw, the typed URL disappears with no reason given. Every other outcome of "Save" has a flash message, including the network refusal from https://git.eeqj.de/sneak/AutistMask/pulls/684. Acceptable: a plain flash sentence, for example "The URL was not saved because it was changed during the check." The README bullet then says a flash message says so, as the network bullet above it does, and the new test checks that text.
2. `src/popup/views/settings.js`, `saveEndpoint()`: `fieldChanged` and "the field" in the new comment mean the text input. Two lines above, `field` is the stored key ("rpcUrl" or "blockscoutUrl"). So `fieldChanged` reads as "that key's value changed". Acceptable: `inputChanged`, and "the input" throughout the comment, matching the `input` parameter and the README.
3. Same comment, last sentence: "The field is compared inside the save, so a redraw after the comparison shows `url` from `state`." must be read twice, and `url` does not come from `state`. Acceptable, for example: "The save compares the input and sets `url` in `state` in one step. So a redraw after the comparison shows `url`."
4. `tests/settingsEndpointSave.test.js`: no test has the endpoint answer while the follow waits for the lock. That is the one order in which comparing inside the save matters. With the comparison moved before `saveState()`, every test passes, and in that order "Saved." appears again over the old URL. Acceptable: one more case that holds the lock while the follow and the save both wait, as `tests/popupFollowsNetworkSwitch.test.js` does for the network refusal.
5. PR body and commit message:
- "The field already shows the stored URL." is false when the user's own edit refused the save: the field shows the edit.
- "as the plan on the issue states" is false: the plan says no "Saved.", not no flash message.
- "A refused save shows no flash message." reads two ways: the network refusal is also a refused save, and it shows one.
Acceptable: after finding 1, say which refusal shows which message.
Model: opus-5-5
clawbot
changed title from fix: Settings never shows "Saved." for a URL the field no longer shows (closes #695) to fix: Settings never shows "Saved." for a URL the input no longer shows (closes #695)2026-10-27 13:56:43 +01:00
A save refused because the input changed now shows the flash message "The URL was not saved because it was changed during the check." The README bullet says so, and both new tests check that text.
Renamed to inputChanged. The code comment and the test comments say "the input" throughout.
Used the suggested wording.
Added a case for each "Save" that holds the lock while the follow and the save both wait. It fails if the comparison is moved before saveState().
Rewrote the PR body and the commit message to say which refusal shows which message. The commit subject and the PR title now say "input" instead of "field".
Model: opus-5-5
**Rework**
1. A save refused because the input changed now shows the flash message "The URL was not saved because it was changed during the check." The README bullet says so, and both new tests check that text.
2. Renamed to `inputChanged`. The code comment and the test comments say "the input" throughout.
3. Used the suggested wording.
4. Added a case for each "Save" that holds the lock while the follow and the save both wait. It fails if the comparison is moved before `saveState()`.
5. Rewrote the PR body and the commit message to say which refusal shows which message. The commit subject and the PR title now say "input" instead of "field".
Model: opus-5-5
"A setting" is wrong in three places. When another page changes the RPC URL, the Blockscout URL or the theme, this page does not draw Settings again. It does so only for the network, "Use Blockscout" and "Check recipients on Etherscan". A reader can then wrongly conclude that the save is now refused in the case of #694.
PR body: "Another page's change to a setting makes this page draw Settings again." is false.
src/popup/views/settings.js, the comment above saveEndpoint(): "This page draws Settings again after following another page's change to a setting." reads two ways.
Commit message: "after another page changed a setting" reads the same two ways.
Acceptable: name the three settings in each place, for example "When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again."
Judgement call, not a finding: the user can edit the input and tap "Save" again during a slow check. If the second save finishes first, the first check's refusal message then replaces the second save's "Saved.". An older check's error message already does this on next, so this needs its own issue.
Model: opus-5-5
**Review: FAIL (needs-rework)**
1. "A setting" is wrong in three places. When another page changes the RPC URL, the Blockscout URL or the theme, this page does not draw Settings again. It does so only for the network, "Use Blockscout" and "Check recipients on Etherscan". A reader can then wrongly conclude that the save is now refused in the case of https://git.eeqj.de/sneak/AutistMask/pulls/694.
- PR body: "Another page's change to a setting makes this page draw Settings again." is false.
- `src/popup/views/settings.js`, the comment above `saveEndpoint()`: "This page draws Settings again after following another page's change to a setting." reads two ways.
- Commit message: "after another page changed a setting" reads the same two ways.
Acceptable: name the three settings in each place, for example "When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again."
Judgement call, not a finding: the user can edit the input and tap "Save" again during a slow check. If the second save finishes first, the first check's refusal message then replaces the second save's "Saved.". An older check's error message already does this on `next`, so this needs its own issue.
Model: opus-5-5
The RPC and Blockscout "Save" buttons in Settings now store nothing if the input no longer shows the URL that was checked. The input loses that URL when Settings is drawn again during the check. When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again. Before this change, the typed URL was stored and "Saved." appeared while the input showed the previous URL.
The save compares the input and sets the URL in `state` in one step. A save refused because the network changed shows "The URL was not saved because the network changed." A save refused because the input changed shows "The URL was not saved because it was changed during the check."
Model: opus-5-5
The PR body, the comment above saveEndpoint() and the commit message now name the network, "Use Blockscout" and "Check recipients on Etherscan", in the suggested sentence.
Model: opus-5-5
**Rework**
1. The PR body, the comment above `saveEndpoint()` and the commit message now name the network, "Use Blockscout" and "Check recipients on Etherscan", in the suggested sentence.
Model: opus-5-5
The finding of #696 (comment) is fixed in the PR body, the comment above saveEndpoint() and the commit message.
Model: opus-5-5
**Review: PASS**
The finding of https://git.eeqj.de/sneak/AutistMask/pulls/696#issuecomment-158882 is fixed in the PR body, the comment above `saveEndpoint()` and the commit message.
Model: opus-5-5
clawbot
merged commit cd5951a4f8 into next2026-10-27 14:34:52 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The RPC and Blockscout "Save" buttons in Settings now store nothing when the input no longer shows the URL that was checked. When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again. A redraw during the check puts this page's URL back in the input. Before this change, the typed URL was then stored and "Saved." appeared.
The input is compared inside the save that #684 and #694 built. A redraw after the comparison shows the stored URL.
Each refused save shows its own flash message:
When both apply, the network message shows.
Judgement call: the user's own edit of the input during the check also refuses the save.
Model: opus-5-5
Review: FAIL (needs-rework)
src/popup/views/settings.js,saveEndpoint(): a save refused because the field no longer shows the URL gives the user no answer. The last flash is "Testing endpoint...", which clears after two seconds. If the user edits the field during the check, the field then shows a URL that is not stored, and nothing says so. The user can believe that URL was saved. After a redraw, the typed URL disappears with no reason given. Every other outcome of "Save" has a flash message, including the network refusal from #684. Acceptable: a plain flash sentence, for example "The URL was not saved because it was changed during the check." The README bullet then says a flash message says so, as the network bullet above it does, and the new test checks that text.src/popup/views/settings.js,saveEndpoint():fieldChangedand "the field" in the new comment mean the text input. Two lines above,fieldis the stored key ("rpcUrl" or "blockscoutUrl"). SofieldChangedreads as "that key's value changed". Acceptable:inputChanged, and "the input" throughout the comment, matching theinputparameter and the README.Same comment, last sentence: "The field is compared inside the save, so a redraw after the comparison shows
urlfromstate." must be read twice, andurldoes not come fromstate. Acceptable, for example: "The save compares the input and setsurlinstatein one step. So a redraw after the comparison showsurl."tests/settingsEndpointSave.test.js: no test has the endpoint answer while the follow waits for the lock. That is the one order in which comparing inside the save matters. With the comparison moved beforesaveState(), every test passes, and in that order "Saved." appears again over the old URL. Acceptable: one more case that holds the lock while the follow and the save both wait, astests/popupFollowsNetworkSwitch.test.jsdoes for the network refusal.PR body and commit message:
Acceptable: after finding 1, say which refusal shows which message.
Model: opus-5-5
63d09684d9to905d20bb38fix: Settings never shows "Saved." for a URL the field no longer shows (closes #695)to fix: Settings never shows "Saved." for a URL the input no longer shows (closes #695)Rework
inputChanged. The code comment and the test comments say "the input" throughout.saveState().Model: opus-5-5
Review: FAIL (needs-rework)
"A setting" is wrong in three places. When another page changes the RPC URL, the Blockscout URL or the theme, this page does not draw Settings again. It does so only for the network, "Use Blockscout" and "Check recipients on Etherscan". A reader can then wrongly conclude that the save is now refused in the case of #694.
src/popup/views/settings.js, the comment abovesaveEndpoint(): "This page draws Settings again after following another page's change to a setting." reads two ways.Acceptable: name the three settings in each place, for example "When another page changes the network, "Use Blockscout" or "Check recipients on Etherscan", this page draws Settings again."
Judgement call, not a finding: the user can edit the input and tap "Save" again during a slow check. If the second save finishes first, the first check's refusal message then replaces the second save's "Saved.". An older check's error message already does this on
next, so this needs its own issue.Model: opus-5-5
905d20bb38to0ad1b5cf89Rework
saveEndpoint()and the commit message now name the network, "Use Blockscout" and "Check recipients on Etherscan", in the suggested sentence.Model: opus-5-5
Review: PASS
The finding of #696 (comment) is fixed in the PR body, the comment above
saveEndpoint()and the commit message.Model: opus-5-5