sieve filter settings: silently discarding unsaved changes when navigating away

unknown commented

2026-09-01 14:05:17 +00:00

The original description was not recovered.

Referenced by commits

coffey-labs/ihasmail@4a99b77bc3 2026-09-02 Highlight saving, not discarding, on the unsaved-changes guard
coffey-labs/ihasmail@d3e173c9c1 2026-09-01 Ask before the filter editors lose your changes

_{Rebuilt from: notification email, session transcript. Opening date is approximate.}

*The original description was not recovered.* **Referenced by commits** - coffey-labs/ihasmail@4a99b77bc383 2026-09-02 Highlight saving, not discarding, on the unsaved-changes guard - coffey-labs/ihasmail@d3e173c9c16b 2026-09-01 Ask before the filter editors lose your changes <sub>Rebuilt from: notification email, session transcript. Opening date is approximate.</sub>

jcoffey-dev commented

2026-09-01 15:23:08 +00:00

Owner

Fixed in #177, and live now on ihasmail.com as 2026.9.1+pr177.

I went with your first suggestion — the guard — rather than saving everything instantly. The deciding factor was that a rules save also activates the ihasmail script, so an implicit save could quietly take over from another active script without anyone asking for it. The guard offers Save / Discard / Stay here rather than a yes-or-no "leave without saving?", since the latter makes losing the work the easy answer.

It holds for every way out of the page: the settings nav, the app rail, and the Rules/Scripts switch (which never reaches the router, so it asks for itself). Reload and tab close get the browser's own prompt. The one gap is the back button — by the time the page hears about it the history has already moved, and holding it would mean pushing an entry back, which breaks the button for everyone with nothing pending.

You were right that the missing indicator was half the problem, so the save bar is now pinned to the foot of the pane with an "Unsaved changes" marker, on screen whether or not the rules fit in the window.

The raw script editor is covered too — losing a hand-written script that way was the worse version of this. Two bugs turned up in it on the way past: saving left the editor open with the name field unlocked, so a second save created a duplicate script instead of updating the one just written.

Thanks for the detail in the report, and for the heads-up about the queue behind it.

Fixed in #177, and live now on ihasmail.com as 2026.9.1+pr177. I went with your first suggestion — the guard — rather than saving everything instantly. The deciding factor was that a rules save also *activates* the ihasmail script, so an implicit save could quietly take over from another active script without anyone asking for it. The guard offers Save / Discard / Stay here rather than a yes-or-no "leave without saving?", since the latter makes losing the work the easy answer. It holds for every way out of the page: the settings nav, the app rail, and the Rules/Scripts switch (which never reaches the router, so it asks for itself). Reload and tab close get the browser's own prompt. The one gap is the back button — by the time the page hears about it the history has already moved, and holding it would mean pushing an entry back, which breaks the button for everyone with nothing pending. You were right that the missing indicator was half the problem, so the save bar is now pinned to the foot of the pane with an "Unsaved changes" marker, on screen whether or not the rules fit in the window. The raw script editor is covered too — losing a hand-written script that way was the worse version of this. Two bugs turned up in it on the way past: saving left the editor open with the name field unlocked, so a second save created a duplicate script instead of updating the one just written. Thanks for the detail in the report, and for the heads-up about the queue behind it.

mbunkus commented

2026-09-01 16:03:51 +00:00

Haven't tried it yet, but I do like your description. Thanks!

mbunkus commented

2026-09-02 08:36:59 +00:00

My colleague likes your change but argues that highlighting the "Discard" button is the wrong incentive. Normally the non-destructive/default action is highlighted, which would be "Save".

I concur with her.

My colleague likes your change but argues that highlighting the "Discard" button is the wrong incentive. Normally the non-destructive/default action is highlighted, which would be "Save". I concur with her. <img width="503" height="411" alt="Image" src="https://github.com/user-attachments/assets/d7a2068c-197b-4776-80c1-44bd3b04b771" />

jcoffey-dev commented

2026-09-02 14:54:17 +00:00

Owner

Changed in #219, live now as 2026.9.2+pr219. Your colleague is right, and it was the wrong way round for exactly the reason she gives.

"Save changes" is now the highlighted answer. "Discard changes" is still marked as the destructive one, but it's drawn the way a destructive item in a menu already is here — a red label on the ordinary surface — rather than as a filled red button. In a list of answers a filled button doesn't read as this one is destructive, it reads as this one is the default, which is precisely backwards on a dialog that exists to stop you losing work.

One consequence worth stating, since it's a change you didn't ask for: the calendar's "this occurrence or the whole series" question uses the same dialog, and marks both answers destructive because both delete something. It goes from two filled red buttons to two red labels with nothing highlighted. I think that's right — neither answer there is the safe one, so neither should look like the default — but if it reads worse to you, say so.

Checked in both themes. Light is #dc2626 on white, 4.8:1; dark uses each palette's own tuned danger colour.

Thanks for pushing back on this one. The guard was the right shape and I got the emphasis exactly wrong.

Changed in #219, live now as `2026.9.2+pr219`. Your colleague is right, and it was the wrong way round for exactly the reason she gives. "Save changes" is now the highlighted answer. "Discard changes" is still marked as the destructive one, but it's drawn the way a destructive item in a menu already is here — a red label on the ordinary surface — rather than as a filled red button. In a list of answers a filled button doesn't read as *this one is destructive*, it reads as *this one is the default*, which is precisely backwards on a dialog that exists to stop you losing work. One consequence worth stating, since it's a change you didn't ask for: the calendar's "this occurrence or the whole series" question uses the same dialog, and marks **both** answers destructive because both delete something. It goes from two filled red buttons to two red labels with nothing highlighted. I think that's right — neither answer there is the safe one, so neither should look like the default — but if it reads worse to you, say so. Checked in both themes. Light is `#dc2626` on white, 4.8:1; dark uses each palette's own tuned danger colour. Thanks for pushing back on this one. The guard was the right shape and I got the emphasis exactly wrong.

mbunkus commented

2026-09-03 07:37:23 +00:00

the calendar's "this occurrence or the whole series" question uses the same dialog, and marks both answers destructive because both delete something. It goes from two filled red buttons to two red labels with nothing highlighted. I think that's right — neither answer there is the safe one, so neither should look like the default — but if it reads worse to you, say so.

I actually agree with that decision as there's no obvious correct or best or usual answer. Any of those two can be applicable at any point. Therefore none should have preferred status.

Thanks.

> the calendar's "this occurrence or the whole series" question uses the same dialog, and marks both answers destructive because both delete something. It goes from two filled red buttons to two red labels with nothing highlighted. I think that's right — neither answer there is the safe one, so neither should look like the default — but if it reads worse to you, say so. I actually agree with that decision as there's no obvious _correct_ or _best_ or _usual_ answer. Any of those two can be applicable at any point. Therefore none should have preferred status. Thanks.

sieve filter settings: silently discarding unsaved changes when navigating away #175