Modified status only appears for a second then disappears

[laurali42]

See attached video

Screen.Recording.2026-09-18.at.11.02.53.AM.mov

[ww-mw]

Thanks @laurali42. Reproduced the behaviour and found two separate mechanisms behind it. One is working as designed and changing it is a product decision; the other is a genuine latent bug. Neither clears my confidence gate tonight, so I'm capturing both rather than guessing.

Mechanism 1 — "Modified" means differs from the last save, not edited this session

That is the pinned rule: the per-URI baseline (src/host/slddBaseline.ts) is captured on open and re-captured after every save, and a row is Modified when its canonical JSON differs from that baseline. Two existing tests pin it — test/dirtyLifecycle.test.ts:114 and test/binaryDirtyLifecycle.test.ts:88.

The consequence, and I think this is your report exactly: with "files.autoSave": "afterDelay" (VS Code's delay defaults to 1000 ms), the file saves about a second after you stop typing, the baseline is re-captured, and every Modified mark clears on its own — no editor close, no action from you. It looks like the marks vanished at random; really, a save happened silently between keystrokes.

Changing this would mean editing those two existing tests, which is exactly the signal that the current behaviour is intentional rather than accidental. So it is a decision, not a fix.

@laurali42 — one closed question that tells us which mechanism you hit: what is your files.autoSave set to (Settings → search files.autoSave; off, afterDelay, onFocusChange, or onWindowChange)? If it is anything but off, mechanism 1 explains it fully and the marks are clearing on save. If it is off, then it is mechanism 2 below and I can fix it.

Mechanism 2 — a real bug: a second panel's close wipes the baseline

Independent of autosave, SlddTextEditorProvider tracks initialized per panel but calls clearBaseline(uriString) on any panel dispose (src/host/SlddTextEditorProvider.ts:1822), and the store is keyed by URI. So: open the same dictionary in two tabs (or split the editor), close one, and the surviving tab's baseline is gone. With no baseline, computeModified returns an empty set by design — so every Modified mark disappears from a tab you are still working in, with unsaved edits intact underneath.

This is the same bug BinarySlddEditorProvider already fixed by scoping it to the document (document.baselineCaptured, and clearing only if (document.views.size === 0)). So it is the recurring "one rule, two paths" shape here: the text path never got the fix. The correct behaviour is unambiguous — the other provider defines it — and the fix is local to the one file, so this is a confident fix. It is not tonight's, because this run's one fix slot went to #24, and it wants a reproducing integration test that opens two panels on one URI.

Options

(a) Fix mechanism 2 only (next run) — reference-count the baseline per document the way the binary provider does. No existing test changes, no behaviour question. Do this regardless of the answer above.

(b) Also keep marks across a save — e.g. Modified means differs from the on-open state until the editor closes, or a separate "edited this session" cue. This needs the two pinned tests rewritten and a decision about what the mark means, especially with autosave on where "since last save" is nearly always empty.

(c) Make the existing rule visible — leave the semantics, but say what happened (e.g. a hint that autosave cleared the marks). Cheap, and honest, but it is a consolation prize if what you want is to see your edits.

I'd recommend (a) unconditionally, then (b) only if your answer is files.autoSave: off-and-still-broken, or if the team decides the mark should survive a save.

[ww-mw]

Following up with an answer rather than more options.

This is autosave, and it's a general VS Code setting rather than something specific to this extension. Timing the attached video frame by frame, the Modified marks live for exactly 1000 ms — which is files.autoSaveDelay's default. So with "files.autoSave": "afterDelay", VS Code saves the dictionary about a second after you stop typing, and because Modified means "differs from the last save", there is nothing left to mark once the save lands. Nothing is lost — the values you entered are on disk.

Our decision is that the extension should follow VS Code's own save behaviour, not override it for its own editors. Two reasons:

• A dictionary in JSON format can be open in the plain text editor at the same time as the table view. Both are views of one file, so both have to honour the same save policy — an editor that quietly ignored your workspace's setting, and left a dictionary unsaved when the rest of the window had saved everything, would be the more surprising bug.
• files.autoSave is a workspace/user-level setting that applies to every file you edit. Special-casing .sldd inside the extension would mean this one file type behaved differently from everything else in your editor, decided by us rather than by you.

If you prefer explicit saves, the setting is yours to change — "files.autoSave": "off" restores Ctrl/Cmd+S-only behaviour (which is what makes the Modified column behave the way it does in Simulink, where saves are always deliberate). If you'd rather keep autosave for source files and turn it off only for dictionaries, scope it by language:

"[json]": { "files.autoSave": "off" }

Separately, and thanks for this: looking into your report turned up a genuine bug nearby. If the same dictionary was open in two tabs and you closed one, the surviving tab lost every Modified mark while your unsaved edits were still there. That one is fixed in v1.24.6.