Version: iOS 12. To reproduce: 1. Go to jsfiddle.net 2. Request desktop site using the Share sheet 3. Tap in the HTML editor and begin typing Expected: only the page's custom text editing caret to show up Observed: both the native iOS editing caret and the page's caret are visible. The native editing caret falls out of sync with the custom caret after deleting text. Additional note: reproducible on codecademy.com as well, which also uses CodeMirror.
<rdar://problem/45971041>
Created attachment 358472 [details] Patch
Created attachment 358478 [details] Patch
Comment on attachment 358478 [details] Patch Attachment 358478 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/10654743 New failing tests: js/dom/custom-constructors.html
Created attachment 358480 [details] Archive of layout-test-results from ews202 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews202 Port: win-future Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit
Created attachment 358499 [details] Patch
Comment on attachment 358499 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=358499&action=review > Source/WebKit/ChangeLog:14 > + When requesting desktop site on iOS, both CodeMirror's caret and the native iOS caret are shown because the > + caret is rendered in the UI process on iOS, whereas on macOS, the entire textarea (along with the caret) are it's really about the selection being pulled out of z-order, right? (everything is "rendered in the UI process" in some sense) > Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:156 > - FocusedElementIsTransparent = 1 << 0, > + FocusedElementIsNotVisible = 1 << 0, Is this promising too much? There are many kinds of occlusion it doesn't cover.
Comment on attachment 358499 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=358499&action=review >> Source/WebKit/ChangeLog:14 >> + caret is rendered in the UI process on iOS, whereas on macOS, the entire textarea (along with the caret) are > > it's really about the selection being pulled out of z-order, right? (everything is "rendered in the UI process" in some sense) That's right, it's about selection UI being rendered as a platform overlay on top of all page content. I'll reword the ChangeLog to make this clearer. >> Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:156 >> + FocusedElementIsNotVisible = 1 << 0, > > Is this promising too much? There are many kinds of occlusion it doesn't cover. 👍 I'll change this from FocusedElementIsNotVisible to FocusedElementIsTransparentOrFullyClipped. It's true that this still doesn't cover many cases of occlusion, but at the very least if this flag is set, we know the focused element must be hidden from the user.
Created attachment 358506 [details] Patch for landing
Comment on attachment 358506 [details] Patch for landing Clearing flags on attachment: 358506 Committed r239685: <https://trac.webkit.org/changeset/239685>