event form: fn+delete closes existing text edits

[tyler-dane]

Bug report

On mac keyboards, pressing Fn+Delete while editing an existing event title or description closes/deletes the active edit form instead of performing the native forward-delete text-editing action. This affects users editing already-saved event text fields, where Fn+Delete is expected to delete the character ahead of the caret.

Where it happened

Compass web event editing forms, reported on mac keyboard input while editing an existing title or description. Likely affected areas are the saved timed event form and saved someday event form.

Workflow

1. Open an existing event that already has a title or description.
2. Focus the title or description text field and place the caret before existing text.
3. Press Fn+Delete on a mac keyboard.
4. Instead of forward-deleting text, the form closes/deletes.

Expected outcome

Fn+Delete should behave like native macOS forward delete inside title and description fields. It should not trigger the event form delete/close shortcut while a text input or textarea is focused.

Screenshot

[screenshot]

Diagnosis

Not browser-reproduced in this capture pass, but code inspection strongly supports the report. In packages/web/src/views/Forms/EventForm/EventForm.tsx, the form registers a bare Delete hotkey that calls onDelete() for existing events or onClose() for drafts via useAppHotkey("Delete", ...) with EVENT_FORM_PLAIN_HOTKEY_OPTIONS. The title and description key handlers only stop propagation for Backspace, not Delete, so macOS Fn+Delete can reach the form-level shortcut instead of staying a text-editing action.

The someday form has the same risk in two places: packages/web/src/views/Forms/SomedayEventForm/useSomedayFormShortcuts.ts registers useAppHotkey("Delete", stopPropagationWrapper(onDelete), { ignoreInputs: false }), and packages/web/src/views/Forms/SomedayEventForm/SomedayEventForm.tsx handles form-level Delete while its ignoreDelete input handler only stops Backspace. The strongest related open issue is #1843, which is about consolidating Day and Week event editing behavior, but this appears to be a distinct keyboard bug.

Focused verification run: bun test --cwd packages/web src/views/Forms/EventForm/EventForm.test.tsx passes 11 tests. Running the same test file directly from the repo root without the web package preload fails during environment setup, so use the package-scoped command above for regression coverage.

Confidence: high for the shortcut/input conflict; medium on the exact close-vs-delete product path until browser reproduction confirms whether the reported closure follows delete confirmation, draft close, or parent form teardown.

Likely fix

Start in packages/web/src/views/Forms/EventForm/EventForm.tsx, packages/web/src/views/Forms/SomedayEventForm/SomedayEventForm.tsx, and packages/web/src/views/Forms/SomedayEventForm/useSomedayFormShortcuts.ts. Ensure bare Delete shortcuts do not run when the event target is a text-editing element (input, textarea, or contenteditable), while preserving explicit delete actions from action menus and any intended non-text-field Delete shortcut. Add regression tests that focus title and description fields, dispatch a Delete key event, and assert onDelete/onClose are not called and default text editing is not prevented.

Verification

1. Add focused web tests for EventForm and SomedayEventForm title/description fields that dispatch Delete with the field focused and assert the form remains open and delete callbacks are not called.
2. Run bun test --cwd packages/web src/views/Forms/EventForm/EventForm.test.tsx and the corresponding someday form tests.
3. Manually verify in bun dev:web on macOS: edit an existing title/description, press Fn+Delete, and confirm the character ahead of the caret is removed while the form stays open.