[Copilot]

Pasting into the middle of a note on iOS added a line break and moved the caret to the end of the note. The issue also reports that Android drops the caret and keyboard; that did not reproduce in emulated Android Chrome, so this PR has only been checked against the iOS failure.

Cause: WebKit's paste inserts the text wrapped in a styled span plus a \n:

Sed <span style="caret-color: …">Ipsum</span>
tortor nunc

Note's onChange then stripped that markup. The saved value no longer matched the DOM, so react-contenteditable rewrote innerHTML, which keeps the line break and drops the caret position.

Changes

• src/components/Note.tsx: onPaste now handles the paste itself.
  • It reads text/plain (or text/uri-list), calls preventDefault(), and inserts the text with document.execCommand('insertText', false, text). The caret lands after the pasted text and the DOM matches the saved value.
  • If the clipboard has no text, it falls back to the browser's paste and the justPasted strip in onChange, as before ([iOS PWA] Cannot import url #286).
  • Unlike thought paste (useOnPaste), a note does not run importData. A multi-line paste stays literal text in the note, as it did before.
• src/e2e/iOS/helpers/tapEditMenuItem.ts (new): taps a named item (Copy, Paste, …) in the native iOS edit menu. This is the native-context logic that used to live in pasteFromEditMenu, which now calls it.
• src/e2e/iOS/__tests__/caret.ts: new regression test. It copies "Ipsum" from the thought through the native menu, then pastes it between "Sed " and "tortor" in the note. It expects the note to read Sed Ipsumtortor nunc with the caret at offset 9.
  • It passed on a BrowserStack iPhone in the Capacitor app. In CI's mobile Safari it fails at the Copy step ("no native edit menu appeared") and never reaches the paste.
  • The copy step needs another way to raise the menu, or to fill the clipboard, before the iOS check can go green.
• docs/cursor-and-caret.md: notes how a note handles paste.

• Fixes [Mobile] Caret is placed at the end of the Note when user pastes into the middle of the Note #3828

[github-actions]

Preview Deployment · Oct 27, 2026, 11:05 PM UTC · a360992

[BayuAri]

@copilot
Please address the failing Check

[Copilot]

@copilot
Please address the failing Check

Fixed the failing BrowserStack (iOS) check in 9749cf2, and it's green on that commit along with Lint, Test, Puppeteer and BrowserStack Android. TDD was still running when I posted this.

• New note-paste test: showEditMenu tapped the selection without converting it to screen coordinates. In mobile Safari that lands 60px above the selection, under the browser chrome, so no edit menu appeared. It now adds getScreenOffsetY, the same way tap does.
• Note-scrub test ([iOS] Caret disappears after using virtual keyboard trackpad #3276): this was the existing test where the tap landed on the parent thought while the note was still scrolling into place. I cherry-picked waitForElementAtRest from Place new thoughts last in Created-sorted contexts that have a bullet style #5863 (ffe5e08), and the new test waits for the note to stop moving too.

Both tests passed in the iOS run.

[BayuAri]

Confirmed fixed.
Text is pasted without adding extra line breaker and caret remain where it is left off accordingly (not moved to the end of the note or even disappear)

[trevinhofmann]

LGTM, thank you!

[raineorshine]

Is this the browser's default behavior of scrolling the focused input to the center of the viewport? Can it be prevented, or does that have to wait for the various autoscroll bugs to be fixed?

It's not ideal to have to wait for a smooth scroll in a test that is about caret placement.

[BayuAri]

@copilot Please answer the question above in this thread. Explanation only: don't change any code.

Pointers:

• The scroll comes from our own scrollCursorIntoView (src/device/scrollCursorIntoView.ts), which uses behavior: 'smooth' when the cursor is less than a viewport away. It is not the browser's native focus autoscroll, which preventAutoscroll already suppresses for notes and thoughts.
• scrollCursorIntoView and scrollTo already scroll instantly under automation (navigator.webdriver ? 'instant' : behavior). Appium leaves navigator.webdriver false in mobile Safari, so that guard never fires on iOS.
• disableTransitions only disables CSS transitions. An explicit behavior option also overrides CSS scroll-behavior.
• It can be prevented now without waiting on the autoscroll bugs, e.g. by having the helper coerce smooth window.scrollTo/scrollBy calls to instant. That only removes the animation, though. The cursor scroll is still scheduled on the next tick and throttled to 400ms, so the note can still jump after it is found. Keep waitForElementAtRest for now.

[Copilot]

It's not the browser's default. The scroll is em's own scrollCursorIntoView (src/device/scrollCursorIntoView.ts). Safari's native scroll-on-focus is already suppressed for notes and thoughts by preventAutoscroll. After the paste moves the cursor, scrollCursorIntoView scrolls with behavior: 'smooth' whenever the distance is less than one viewport height.

There is already an automation guard, navigator.webdriver ? 'instant' : behavior, in both scrollCursorIntoView and scrollTo. On iOS it never fires, because Appium leaves navigator.webdriver false in mobile Safari. disableTransitions doesn't help either: it only turns off CSS transitions, and an explicit behavior option overrides CSS scroll-behavior anyway.

Can it be prevented? Yes, and it doesn't have to wait for the autoscroll bugs. A test helper could force smooth window.scrollTo/scrollBy calls to scroll instantly.

That only removes the animation, though. scheduleScrollCursorIntoView still runs the scroll on the next tick and throttles it to 400ms. So the note can still move after the test has found it, just in one jump instead of a slide. The test would still have to wait for the scroll to finish, and waitForElementAtRest is what does that. I'd keep it until the cursor scroll gives the test something to wait on, such as a signal that it has finished.

No code changes in this reply, as requested.