Selection gets out of sync when tapping into text while a toolbar input is focused

[johannesmutter]

What happens

While the toolbar's URL input is focused, tap into a different node's text — for example from one button's text into another button's text. The caret visibly moves to the new button, but the toolbar still shows the previous button's data (e.g. its link URL). The selection debug panel confirms the model selection still points at the old node.

Why

While an app input has focus, canvas_focused is false and onselectionchange deliberately ignores selection changes (src/lib/Svedit.svelte) — so typing in inputs isn't misread as canvas selections.

On iOS Safari, tapping into text fires selectionchange before the canvas gets its focus event. That one event falls into the ignored window and no further selectionchange comes after focus settles. Result: the visible caret and the model selection are out of sync until the next tap or keystroke.

Suggested fix

When the canvas regains focus (handle_canvas_focus), read the current DOM selection once and map it to the model — the same thing onselectionchange does. That picks up any caret placed during the unfocused window.

Related: #342 (same family — toolbar inputs vs. canvas focus).

[michael]

Can't reproduce. Did you confirm the URL with ENTER? (we don't save on keystroke here, as an url change should be a single set of a string)

I think the real fix here is an explicit modal flow for URL editing (see how editable.website does it; first shows an url preview beneath the link, then clicking edit opens a modal, you can then confirm or dismiss, then it's clearer when the value is updated and when not). I didn't implement the whole flow here yet to keep the svedit demo low-code and easier to navigate for someone that wants to just get familiar with the svedit api's. Quick fix would be an explicit "update" button next to the URL field (though that's ugly).

Not completely sure what the scope/purpose of the demo code best should be:

• shouldn't grow to become like a full app
• but at the same time, shouldn't look ugly / turn people off
• not sure how best hit the sweet spot here, i mean it's nice to also try out new paradigms in the svedit demo (like inline formatting tools) and make it all look decent and nice, but we should not forget it's main purpose was to be a code-demo for starters. That shouldn't be lost on the way.

[johannesmutter]

Two separate things got stacked in my report untangling them below:

1. The desync (this issue) is iOS-only (that's why it doesn't reproduce on desktop). On iOS, tapping into text fires selectionchange before the canvas receives its focus event. The event lands in the window where onselectionchange deliberately ignores changes (canvas_focused is still false because focus was on the URL input), and no second selectionchange follows once focus settles. The model keeps the old selection while the visible caret sits in the new spot. Repro needs to be done in iOS Safari: focus the URL input, then tap directly into another button's text. Suggested fix stays as in the description: re-map the DOM selection once when the canvas regains focus.

2. The URL saving: correct, I hadn't confirmed with Enter (I assumed save on blur). And the Enter-only commit made bug 1 look extra confusing: since the model selection didn't move, the input's bound value didn't change either, so my typed text just stayed visible and looked "saved".

This is purely about UX and an experiment: I currently made the inputs also commit on change (i.e. on blur). Still exactly one set per edit session (no keystroke-level sets) with an unchanged-value guard so Enter followed by blur can't produce a duplicate history entry, and Escape resets the field first so cancel still cancels. No extra button, no modal, a few lines. Enter could be also interpreted as close this toolbar, vs. pure blur not, unless you click outside.