## Problem/Motivation `useDebouncedField` commits a pending edit through **two different handler identities**, depending on how the commit is triggered. The debounce timer calls the handler from the render where the typing happened — which is correct. `flush()`, the unmount cleanup and `onBlur` all call the **current** handler instead. When the selected component changes while an edit is pending, the current handler belongs to the **newly selected** component. So the flush writes the old component's typed text onto the new one, and the component that was actually edited receives nothing. A four-line diagnostic isolates it — `handlerA` belongs to the edited component, `handlerB` to the newly selected one: ``` TIMER -> handlerA: [ [ 'Alpha EDITED' ] ] handlerB: [] correct FLUSH -> handlerA: [] handlerB: [ [ 'Alpha EDITED' ] ] wrong UNMOUNT-> handlerA: [] handlerB: [ [ 'Alpha EDITED' ] ] wrong BLUR -> handlerA: [] handlerB: [ [ 'Alpha EDITED' ] ] wrong ``` Cause: the `setTimeout` closure in `onChange` captures `onDebouncedChange` from the render where the keystroke landed. `flush` is a `useCallback` memoized on `[disabled, onDebouncedChange, value]`, so it captures whatever is current at render time. `PropertyPanel` is the caller that exposes this, at `:518-526` (node) and `:528-535` (edge): those identity effects call `flush()` *after* `node` / `edge` has already become the new one. ### Observed payloads Driving the real `PropertyPanel` with the real hook and real panels — node A is `Alpha`/`Alpha note`, node B is `Beta`/`Beta note`: ``` node label: onConfigurationChange = [["node-b",{"_componentLabel":"Alpha EDITED"}]] node annotation: onNodeUpdate = [["node-b",{"label":"Beta","annotation":"Alpha note EDITED"}]] edge annotation: onEdgeUpdate = [["edge-b",{"annotation":"Edge A note EDITED"}]] ``` It is a double fault: the text lands on the wrong component **and** the edited component is left unchanged. The annotation case corrupts only the annotation — note `label` correctly stays `"Beta"`. Reproduced in Chromium end-to-end as well: ``` event_1 canvas text = "EVENT\nOn Entity Insert" <- the user's edit, lost action_1 canvas text = "ACTION\nEVENT EDITED" <- landed on the wrong node ``` ## No UI sequence reproduces this — please do not close it as unreproducible **Clicking another component is safe, and it is worth understanding why before trying to reproduce by hand.** A native mouse click fires `blur` during **mousedown**, i.e. *before* the click handler that changes the selection. `onBlur` clears the timer and commits to the still-correct component, so by the time the identity effect runs, `debounceTimer.current === null` and `flush()` does nothing. Verified in Chromium — `blur events seen = 1`, and both nodes keep the right text. Every other route to a selection change was checked and is also safe: | Route | Why it does not reproduce | |---|---| | Keyboard shortcuts | blocked inside form fields — `isInFormField`, `useKeyboardShortcuts.ts:43-49` | | Search | requires focusing the search box, which blurs the field | | `selectAndFocus` | only called from `useModelDataLoader` on model load | | Replay selection | happens in replay mode, where the label input is not mounted | | Node deletion | selection becomes null; `handleNodeLabelChange`'s `if (node)` guard makes the flush a silent no-op — the edit is lost, but nothing is misattributed | **The one live route is the public plugin API**: `pluginApi.ts:306` `selectNode(nodeId: string | null)`. It changes selection with no pointer event, so nothing blurs. A plugin that calls `selectNode()` while the user has an uncommitted edit in the property panel silently corrupts the model. The browser reproduction above used a dispatched click as a faithful stand-in for that. ## This is older than #3589113 and unaffected by it Reverting `useDebouncedField.ts` to its pre-#3589113 state at `3a75f45` and re-running produces **byte-for-byte identical output**. The #3589113 guard only decides whether `setValue` runs; `setValue` is asynchronous and cannot change what `flush` already captured in the same commit. So this defect predates that fix and survives it untouched. ## Proposed resolution **Capture the handler when the timer is armed, not when it fires.** In `onChange`, store the handler in a ref alongside the timer, and have `flush()` and the unmount cleanup invoke *that* handler rather than the current one. This aligns the three wrong exits with the timer path that is already correct, fixes all three fields at the hook level, and has the side benefit of making `flush` stable — no `value` / `onDebouncedChange` dependencies. Leave `onBlur` as it is: it fires *before* the component changes, and it uses the freshest DOM value. Rejected alternatives: 1. **Flush before the component changes** — the identity effect only learns about the change after the fact, so there is no earlier point to hook. 2. **Capture the component at each call site** — three duplicated fixes in `PropertyPanel` instead of one in the hook, and the next caller repeats the mistake. ## Severity Low-to-medium. Not an everyday bug: no ordinary interaction triggers it. But it is silent model corruption with no error and no visual cue, it both writes to the wrong component and loses the edit from the right one, and it is reachable from a supported public extension point. It is the same profile as #3589113 — a fault that survives unnoticed because nothing routine reaches it. ## Remaining tasks - [ ] Move the handler capture into a ref armed with the timer - [ ] Cover all three fields: node label, node annotation, edge annotation - [ ] Cover the unmount path as well as `flush()` — both exits share the fault - [ ] Regression test that does **not** blur before switching selection, since a blur hides the defect - [ ] Consider whether `PropertyPanel.test.tsx` should stop mocking the hook wholesale (`:98-109` replaces it with `flush: jest.fn()`), which is why no existing test could catch this ## Existing test coverage None of it could have caught this. `PropertyPanel.test.tsx:98-109` mocks the entire hook. `label-editing.spec.ts` calls `.blur()` before every selection switch. `property-panel.spec.ts` never edits and then switches. ## User interface changes None. The visible effect is that an edit can no longer be written onto the wrong component. --- Note: this issue was drafted by an AI agent. Every claim above was established by reproduction — a jsdom repro against the real components, a Chromium run for the blur ordering, and a handler-identity diagnostic — not by reading the code. Verified against `1.0.x` at `5ad3ecc`.