Require confirmation before deleting elements in manual edit mode

[AmyShang-alt]

Summary

Deleting an element from the manual edit popover happens immediately without a second confirmation step.

Current behavior

In manual edit mode, selecting an element opens the style/edit popover with a Delete element action. Clicking Delete element removes the selected element right away.

There is no confirmation dialog, destructive-action prompt, or other guard before the element is deleted.

Expected behavior

Deleting an element should require a second confirmation before the element is removed, especially because this action is destructive and can affect generated design output.

For example:

• Click Delete element.
• Show a confirmation prompt such as Delete this element?.
• Only delete after the user confirms.

Steps to reproduce

1. Open a generated design artifact in Preview.
2. Enter manual edit mode.
3. Select any editable element.
4. Click Delete element in the edit popover.
5. Observe that the element is deleted immediately.

Notes

The screenshot shows the Delete element button in the manual edit popover. This is related to destructive edit safety; issue #2866 covers undo behavior after deletion, while this report focuses on the missing pre-delete confirmation.

Why this matters

Users can accidentally remove parts of a design with one click, with no chance to confirm the destructive action before it happens.

[lefarcen]

Hey @AmyShang-alt — thanks for writing this up so clearly. I checked the current manual-edit path and this should already be guarded on main: ManualEditPanel now flips the trash action into a confirm state before it applies the remove-element patch, and #1516 added that flow while #2866 is tracking the separate undo-after-delete gap.

So at the moment this looks more like either a regression on a specific build, or a delete path that is bypassing the current panel flow. Could you share the exact app build / branch you reproduced on, and whether the first click deletes immediately or first turns the footer into a confirm + cancel state? That would tell us pretty quickly whether we're chasing a release gap or a separate code path.

[lefarcen]

This is open for community contributions — if you'd like to work on adding the confirmation step to the delete-element flow, comment /claim to pick it up!

[maxmilian]

I took a look to help triage this — the confirm-before-delete flow @lefarcen mentioned does appear to be present on current main. In apps/web/src/components/ManualEditPanel.tsx:

• The panel tracks a confirmDelete state (useState(false)).
• The trash button's first click only runs setConfirmDelete(true) — it does not delete; it flips the footer into a confirm state.
• The element is removed (the { id, kind: 'remove-element' } patch via onApplyPatch) only from the separate confirm-action button, which is shown alongside a Cancel button.

So a first click on "Delete element" turns into confirm + cancel, and the element is removed only on the second (confirm) click — which matches the expected behaviour described here.

@AmyShang-alt — if you're still seeing an immediate delete, could you share the exact app build/branch? That would tell us whether it's a release-specific regression or a delete path bypassing ManualEditPanel. Otherwise this looks safe to close as already-implemented.

[lefarcen]

Thanks for digging into this, @maxmilian — that matches what we're seeing on current main.

The ManualEditPanel path is two-step today, so this no longer looks like a clear open implementation task on HEAD; I've removed the good first issue label to avoid inviting duplicate work. @AmyShang-alt, if you're still seeing a one-click delete, could you share the exact app build / branch (or whether this was on an older preview/release build)? If we can't reproduce that outside an older build, we'll close this as already implemented.