Bug 193180 – Native caret shows up alongside the page's caret when requesting desktop site on jsfiddle.net

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Wenson Hsieh]

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.

[Wenson Hsieh]

<rdar://problem/45971041>

[Wenson Hsieh]

Created attachment 358472 [details]
Patch

[Wenson Hsieh]

Created attachment 358478 [details]
Patch

[EWS Watchlist]

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

[EWS Watchlist]

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

[Wenson Hsieh]

Created attachment 358499 [details]
Patch

[Tim Horton]

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.

[Wenson Hsieh]

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.

[Wenson Hsieh]

Created attachment 358506 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 358506 [details]
Patch for landing

Clearing flags on attachment: 358506

Committed r239685: <https://trac.webkit.org/changeset/239685>