Say so when the browser refuses to save #77

2026-09-01T18:08:28-06:00

jheaps commented

2026-09-01 18:08:28 -06:00

Every save goes through one try/catch, and the catch was empty: Stacked on #76.

} catch {
    // Storage full/unavailable (private browsing, etc.) — the table still works
    // for the rest of the session, it just won't survive a refresh.
}

The comment is accurate and the behaviour is right — the chips have already moved in memory and refusing to continue would be worse. What was missing is anybody being told. Driven with setItem throwing: two saves failed, no toast, nothing on the page, and a refresh came back to before the hand was dealt with the dealer none the wiser.

That's the same shape of fault the bank reconciliation exists for. Silent until it's too late to act on, and the way you find out is the last two players cashing out.

Said twice, for the two timescales

A toast the first time, and only the first time — a dealer taps this bar thirty times a hand and doesn't need thirty warnings. Measured: four failed saves, one toast.

This table isn't being saved — refreshing would lose it. Keep this tab open.

And a standing line at the top of the Session panel, because a toast is a moment and this is a fact about the rest of the night. The raise pad dismisses toasts, and the one warning that must not be missed isn't the one to leave to a toast.

This table isn't being saved — the browser refused. It'll keep working, but closing or refreshing this tab loses the session. Export CSV below keeps a copy.

Amber, like the bank check's disagreement, because both mean the same thing: your record of the night is wrong and you can still do something about it. The export is named because it's the thing that helps.

Validation

6 tests (255 total): a good save reports success and leaves no mark, a failing one reports failure rather than throwing, the listener fires exactly once across twenty failures, it's handed the error so the reason can be reported later, a failing save still doesn't stop the table, and no listener at all isn't an error.

Driven through the UI with setItem throwing: hidden while saving works, toast on the first failure, zero further toasts across three more actions, the panel line present and readable. Contrast clean, layout audit clean, no console errors.

Every save goes through one try/catch, and the catch was empty: Stacked on #76. ```js } catch { // Storage full/unavailable (private browsing, etc.) — the table still works // for the rest of the session, it just won't survive a refresh. } ``` The comment is accurate and the behaviour is right — the chips have already moved in memory and refusing to continue would be worse. **What was missing is anybody being told.** Driven with `setItem` throwing: two saves failed, no toast, nothing on the page, and a refresh came back to before the hand was dealt with the dealer none the wiser. That's the same shape of fault the bank reconciliation exists for. Silent until it's too late to act on, and the way you find out is the last two players cashing out. ## Said twice, for the two timescales **A toast the first time, and only the first time** — a dealer taps this bar thirty times a hand and doesn't need thirty warnings. Measured: four failed saves, one toast. > This table isn't being saved — refreshing would lose it. Keep this tab open. **And a standing line at the top of the Session panel**, because a toast is a moment and this is a fact about the rest of the night. The raise pad dismisses toasts, and the one warning that must not be missed isn't the one to leave to a toast. > This table isn't being saved — the browser refused. It'll keep working, but closing or refreshing this tab loses the session. Export CSV below keeps a copy. Amber, like the bank check's disagreement, because both mean the same thing: your record of the night is wrong and you can still do something about it. The export is named because it's the thing that helps. ## Validation **6 tests (255 total)**: a good save reports success and leaves no mark, a failing one reports failure rather than throwing, the listener fires exactly once across twenty failures, it's handed the error so the reason can be reported later, a failing save still doesn't stop the table, and no listener at all isn't an error. Driven through the UI with `setItem` throwing: hidden while saving works, toast on the first failure, **zero further toasts across three more actions**, the panel line present and readable. Contrast clean, layout audit clean, no console errors.

jheaps added 1 commit 2026-09-01 18:08:29 -06:00

Say so when the browser refuses to save 4071be5329

Every save goes through one try/catch, and the catch was empty:

    } catch {
        // Storage full/unavailable (private browsing, etc.) — the table still works
        // for the rest of the session, it just won't survive a refresh.
    }

The comment is accurate and the behaviour is right -- the chips have already moved in
memory and refusing to continue would be worse. What was missing is anybody being
told. Driven with setItem throwing: two saves failed, no toast, nothing on the page,
and a refresh came back to before the hand was dealt with the dealer none the wiser.

That is the same shape of fault the bank reconciliation exists for. Silent until it is
too late to act on, and the way you find out is the last two players cashing out.

Now it says so twice, in the two places that suit the two timescales.

A toast the first time, and only the first time -- a dealer taps this bar thirty times
a hand and does not need thirty warnings. Measured: four failed saves, one toast.

  "This table isn't being saved — refreshing would lose it. Keep this tab open."

And a standing line at the top of the Session panel, because a toast is a moment and
this is a fact about the rest of the night. The raise pad dismisses toasts, and the one
warning that must not be missed is not the one to leave to a toast.

  "This table isn't being saved — the browser refused. It'll keep working, but
   closing or refreshing this tab loses the session. Export CSV below keeps a copy."

Amber, like the bank check's disagreement, because both mean the same thing: your
record of the night is wrong and you can still do something about it. The export is
named because it is the thing that helps.

6 tests (255 total): a good save reports success and leaves no mark, a failing one
reports failure rather than throwing, the listener fires exactly once across twenty
failures, it is handed the error so the reason can be reported later, a failing save
still does not stop the table, and no listener at all is not an error.

Driven through the UI with setItem throwing: hidden while saving works, toast on the
first failure, zero further toasts across three more actions, the panel line present
and readable. Contrast clean, layout audit clean, no console errors.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb

jheaps referenced this pull request

2026-09-01 18:22:57 -06:00

Don't quietly write over a save that couldn't be read #78

jheaps closed this pull request

2026-09-02 09:57:54 -06:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jheaps/JoshHeaps.Net#77