Repair the closing action before replacing the editor

A frustrating editor can make replacement seem like the obvious answer. First establish whether the failure is broad or whether a specific interaction is doing more than the user intended.

This fictional investigation concerns a product editor with an image-preview dialog inside it. Pressing Escape to leave the preview also closes the editor. The team examines that event before deciding whether the whole publishing application needs to change.

Preserve the starting state

Editor E-28 contains a proposed caption, “Side connection,” and an unsaved note asking the product owner to confirm the image. The editor's ordinary save and explicit close actions work according to the existing design. Its image-preview control opens a second dialog, P-28, above it.

The reviewer opens P-28 and presses Escape once. Both P-28 and E-28 disappear. Reopening the editor restores the last saved record, so the proposed caption and note are no longer in the working form.

This is a fictional observation of the inspected component arrangement. It does not describe the behaviour of every browser's native dialog element.

Trace which layer handles the action

The application has two custom key handlers. The preview treats Escape as a request to close itself. The outer editor's handler also receives the same event and treats it as a request to close the editor. Neither establishes that it owns the active dialog layer before acting.

The stored product record has not changed. The draft values were present immediately before the key event. The loss occurs when the editor is unnecessarily closed, not during a failed save or a database update.

The component stack already identifies the active dialog. That existing capability makes a focused correction possible; the team does not need to invent a new editor to determine which layer should handle Escape.

Choose one owner for the closing action

The repair routes the keyboard close through the component's supported dialog-stack handling. Only the active topmost layer acts. Closing the preview returns control to its trigger in the still-open editor. The outer editor's separate close action retains its existing confirmation behaviour for unfinished work.

The W3C modal-dialog pattern describes keyboard closure, focus behaviour and the relationship between a modal dialog and inactive content beneath it. That guidance informs the review. The specific duplicate handling and repair remain facts of this fictional application.

A blanket instruction to ignore Escape would remove an expected interaction without addressing ownership. Likewise, automatically saving the draft before closing both layers would change the publishing workflow and could persist an unapproved note. Neither is selected.

Complete the discriminating retest

The reviewer repeats E-28 with the same proposed caption and note, opens P-28 and presses Escape once. P-28 closes. E-28 remains open, both working values are intact and focus returns to the preview control. No save or publish request occurs.

They reopen the preview and use its visible close control. The same editor state remains available. They then close the editor through its own explicit control and receive the existing unfinished-work decision. Choosing to continue editing retains the draft.

With no preview open, the editor's supported keyboard-close path still invokes its own unfinished-work handling. A separate help dialog outside the product editor keeps its ordinary close behaviour. These controls show that the repair has not disabled closing generally or redirected every Escape key to E-28.

Decide whether replacement is justified

The fictional team keeps the editor and commissions the bounded interaction repair. Its ordinary editing, approval and publishing tasks meet the current requirement, and the inspected component supports the necessary ownership rule. The evidence does not support paying for a replacement solely to remove this defect.

That decision has limits. It does not settle unrelated performance, security or maintenance questions, and it is not a blanket accessibility assessment. The implemented editor still needs the agreed keyboard, screen-reader and device review for its full scope.

Record the component version, the two layers, the expected focus return and the retained-state checks in the handover. Those details let a future maintainer recognise a recurrence without guessing that every lost draft has the same cause.

Care and takeover can investigate an existing system in this way. Bring the action that fails and the state that should survive it, so the repair-or-replacement decision can rest on evidence.