Prosemirror: “Cut” doesn’t work on iOS

[dgreensp]

Issue details

Copy and paste work on my iPhone and iPad, but “cut” dismisses the keyboard and does not change the clipboard.

Steps to reproduce

Select some text (e.g. on the main demo on the home page) on MobileSafari, and choose “Cut” from the pop-over menu. The keyboard disappears and the clipboard remains unchanged.

The same issue occurs with Command-X on a hardware keyboard attached to an iOS device, and/or running in a WebView in an iOS app.

ProseMirror version

prosemirror-view 1.0.10

[dgreensp]

On the subject of iOS cut/copy/paste in general, treating an iOS Safari "paste" as non-broken seems to be a strict improvement. When it comes to the "broken clipboard" hacks for cut/copy, a major problem is that on iOS, programmatic .focus() is restricted; it can only be done while handling a UI event, not from a setTimeout, for example. If you make one of these disallowed calls to .focus(), it may set document.activeElement, but it doesn't really set keyboard focus or show the keyboard again.

I can use handleDOMEvents to block ProseMirror's handling of cut/copy, which seems to produce good results for plain text. In what cases is ProseMirror's special handling of cut/copy important?

[marijnh]

Do you know since when the clipboard API was properly implemented in mobile safari? In Safari/601.1 it is still broken.

[dgreensp]

In mobile Safari 604.1, getData seems to work, but I haven't been able to get setData to work at all.

There is some indication here that it is supposed to work, but none of the code in this thread is working for me, sadly: https://bugs.webkit.org/show_bug.cgi?id=177715

[marijnh]

Right, that's why iOS is marked as not having a working clipboard API. It's a shame that the kludge used to emulate clipboard access also doesn't work—that means we are pretty much forced to let the native behavior go through, which means that user code trying to influence copy/paste, for example through clipboardParser, won't work on iOS.

Still, that's probably preferable to having things go wrong entirely. I don't have a recent iOS device so I can't test Mobile Safari versions newer than 601.1, but it doesn't sound like a lot changed in this department (which doesn't reflect very well on Apple, but that's another story). I'll try to take some time to look into this soon, but soon might take a while since I have a lot on my plate at the moment.

[jakeknerr]

Can confirm this bug in the latest iOS 10 Safari and the latest iOS 11 Safari.

[wbharding]

@marijnh if it would accelerate progress on this issue, our company would be happy to send you an iOS device that can run the latest version of Safari. This is a pretty frustrating bug to contend with since it removes the cut text, but then provides the user no straightforward means to restore the text they hoped to cut/paste.

[marijnh]

@wbharding Sure, if you prefer that to debugging the issue on your side, that'd work. Please mail me at [email protected] to coordinate this.

[marijnh]

I was able to verify that Mobile Safari 11 has a working clipboard API, so for that version this patch makes the editor use the regular, more reliable code paths.

I'm not too familiar with the upgrade behavior of older Apple devices. Are many people stuck on Safari 10 and older, or will most people have gotten version 11?

[jakeknerr]

iPhone <= 5 users cannot update to iOS 11, and are stuck on iOS 10. iPhone 6,7,8,X are all on iOS 11.

I can tell you that I own an iPhone 5 and I am the only person I know who is still using such an old model. In fact, many of my apps have already stopped working, Pokemon Go causing the most strain with my family.

I wouldn't worry too much about iOS luddites like myself, I think we are pretty rare.

[jordoh]

@marijnh - I can verify that patch fixes the cut behavior in Mobile Safari on iOS 11.3, with the following user agent:

Mozilla/5.0 (iPhone; CPU iPhone OS 11_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1

However, inside webviews (such as the one used by Chrome on iOS), the user agent does not include the Version/... component, so the pre-11 clipboard handling still gets applied.

Here's the user agent in Chrome on the same device:

Mozilla/5.0 (iPhone; CPU iPhone OS 11_3 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/67.0.3396.87 Mobile/15E216 Safari/604.1

Similarly, here's the user agent from a WkWebView (one that isn't customized like Chrome's is) in the Simulator on iOS 11.2:

Mozilla/5.0 (iPhone; CPU iPhone OS 11_2 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Mobile/15C107

Would it make sense to key off of the AppleWebKit/ version being 604+ instead? Presumably the AppleWebKit version is where the clipboard API was fixed, and it's common to the various user agents.

[marijnh]

Would it make sense to key off of the AppleWebKit/ version being 604+ instead?

Yeah, I guess. 603 appears to indicate Safari 10.1, so 604 would indeed be the proper cutoff value.

Could you test attached patch and let me know if it works for you? If so, I'll do another release.

[marijnh]

Oh, and by attached patch I mean this one.

[jordoh]

Thanks @marijnh - I can verify that patch works in iOS Chrome, a standard WkWebView, and still works in Mobile Safari.

[marijnh]

Thanks for verifying that. Released as 1.3.6

[adrianheine]

If I understand correctly, this now works reliably on recent iOS versions, so I'm closing this issue.