This may be a bug report, but in case this is userland behavior to customize I thought I’d open a topic here first.
I often use a Prosemirror-based editor on my phone. The “Find in Page” in Chrome (WebKit) on iPhone does not seem to work.
Here’s a screen recording for reference hosted in a glitch forked from the basic PM example. I created a plain content editable div below the PM editor with the same content. When searching for the string “editable”, the browser identifies two instances - one in PM and one in the div. The browser will scroll to the instance in the content editable div, but not within the PM editor.
The “Find” behavior works as expected in Desktop Webkit (Safari).
Is there something to configure Find in Page to work with an editor?
No, there’s not really much scripts can do with find-in-page interaction. Could you try whether a plain contentEditable div behaves differently from ProseMirror here? If not, this is probably not something the editor can help. (And may be similar to the issue where iOS doesn’t automatically scroll the cursor into view on scrollable editable elements. Mobile Safari is kind of terrible with a lot of these editing corner cases.)
Could you try whether a plain contentEditable div behaves differently from ProseMirror here?
The example contains a plain contentEditable div. Find-in-page works well and performs the scroll behavior there.
And may be similar to the issue where iOS doesn’t automatically scroll the cursor into view on scrollable editable elements
I’m not familiar with this case. What makes a scrollable editable element? contenteditable and an overflow css rule?
I’m not seeing this problem. Interestingly, my find-in-page widget also looks different (gray, and at the bottom of the page, instead of white and at the top as in your screencast). Maybe this got updated/fixed in iOS 14.5.1?
Hmm I can still reproduce the behavior the same as in the previous screen recording.
On my phone I updated to 14.5.1, and running Chrome Version 87.4280.163.
Curious about the UI difference. The UI looks the same for me as previously as well.
Ahh, Chrome. Sorry, I read iPhone and assumed Mobile Safari. Will take another look at this.
What appears to be happening is that Chrome is actually changing the DOM to show search matches, to which ProseMirror responds by fixing up its DOM again, at which point Chrome appears to give up entirely. This may be related to the fact that they are running on a ‘foreign’ rendering engine on iOS, and thus can’t use the features they use for this type of highlighting on Blink-based browsers. I don’t think there’s a reasonable way to fix this on the ProseMirror side.