iOS Safari tap jumps to wrong place when tap lands on a line padding

[lishid]

Describe the issue

So I have a 2-in-1 combo here:

1. When a cm-line has top padding, tapping on the top padding causes Safari to set the selection to be at the the first text character in the line, rather than the character closest to the tap. Chrome is smart enough to do the right thing. Unfortunately I think this may need a kludge since I can't seem to get Safari to behave more like Chrome.
2. When the editor loses focus, and a tap triggers the bug above, if the first character of the line happens to be on a widget (even if the widget is explicitly contenteditable=false!!), the editor completely ignores the selection and resumes the last selection. This happens because the tap triggers focus and selectionchange; focus sets a 10ms timer, and selectionchange catches the selection to be within the widget, which has ignoreEvent returning true, causing the selection to be ignored; subsequently the focus timeout fires and resets the selection to the editor's last know position.

The repro link below sets up a widget at the beginning of the first line, and a CSS style for an exaggerated top padding for cm-view for ease of reproduction. (In our production app, the padding is 1-2px, so the reproduction is seemingly random depending on whether the fat finger hit the 2-4px zone or not)

As demonstrated in the video below from the repro link:
0-5s: Put the cursor at the end of the document (initial setup).
6-9s: Tap on the top padding of line 1 (with the widget at the beginning of line). Notice the cursor is still at the end of the document (bug 2).
10-12s: Tap on the top padding of line 2 (without the widget at the beginning of line). Notice the cursor has been moved to the beginning of line 2 (bug 1).
12s-15s: Repeat with line 1, notice cursor is still at line 2 (bug 2).

ScreenRecording_11-14-2025_22-44-00_1.mov

Browser and platform

iOS 18/26 Safari

Reproduction link

https://codemirror.net/try/#c=aW1wb3J0IHtXaWRnZXRUeXBlLCBEZWNvcmF0aW9uLCBFZGl0b3JWaWV3fSBmcm9tICJAY29kZW1pcnJvci92aWV3IgppbXBvcnQge1N0YXRlRmllbGR9IGZyb20gIkBjb2RlbWlycm9yL3N0YXRlIgpjbGFzcyBUZXN0V2lkZ2V0IGV4dGVuZHMgV2lkZ2V0VHlwZSB7CiAgdG9ET00oKSB7CiAgICBsZXQgZWwgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzcGFuJyk7CiAgICBlbC5pbm5lclRleHQgPSAnXHUyMDBCJzsKICAgIHJldHVybiBlbDsKICB9Cn0KbmV3IEVkaXRvclZpZXcoewogIGRvYzogImNvbnNvbGUubG9nKCdoZWxsbycpXG4iLnJlcGVhdCg1KSwKICBleHRlbnNpb25zOiBbU3RhdGVGaWVsZC5kZWZpbmUoewogICAgY3JlYXRlKCkgeyAKICAgICAgcmV0dXJuIERlY29yYXRpb24uc2V0KFsKICAgICAgICBEZWNvcmF0aW9uLndpZGdldCh7d2lkZ2V0OiBuZXcgVGVzdFdpZGdldCgpLCBibG9jazogZmFsc2V9KS5yYW5nZSgwLCAwKQogICAgICBdKTsKICAgIH0sCiAgICB1cGRhdGUoZGVjb3MsIHRyKSB7CiAgICAgIHJldHVybiBkZWNvczsKICAgIH0sCiAgICBwcm92aWRlOiBmID0+IEVkaXRvclZpZXcuZGVjb3JhdGlvbnMuZnJvbShmKQogIH0pLCBFZGl0b3JWaWV3LnRoZW1lKHsgIi5jbS1saW5lIjogeyBwYWRkaW5nVG9wOiAiMzBweCIgfX0pXSwKICBwYXJlbnQ6IGRvY3VtZW50LmJvZHkKfSkK

[lishid]

Similar to the second issue, we are observing a new rarer case also on iOS Safari. Somehow when the DOM is heavy, Safari fires the selectionchange event way later than the focus event. Because of this, the 10ms timer from the focus event ends up being called first, before the selectionchange event. The user observed effect is that tapping the editor when it was not focused causes the selection to jump back to the last known location, rather than the tapped position.

I am unable to reproduce personally, but two of our users were able to use devtools to log an instance of this issue as follows:

In the screenshot below, we observe 1) the focus event at 449821ms (this is the event.timeStamp), 2) the setTimeout(10) callback at 449836ms (from performance.now()) and 3) the selectionchange event at 449846ms. (total of 25ms difference between the two events)

We've confirmed that the selectionchange event was just somehow delayed, as changing the setTimeout to a larger number (40) fixes the issue.

[lishid]

Any ideas if there's a good way to fix this? I have a workaround for the first one right now but I am getting a fair amount of reports on iOS where tapping the editor to focus puts the cursor in the previously known position instead of where the user tapped (very often at the position 0), which scrolls the user up to the top.

https://forum.obsidian.md/t/ios-cursor-jumping-after-selection/107976