Bug 193180

Summary: Native caret shows up alongside the page's caret when requesting desktop site on jsfiddle.net
Product: WebKit Reporter: Wenson Hsieh <wenson_hsieh>
Component: HTML EditingAssignee: Wenson Hsieh <wenson_hsieh>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, commit-queue, ews-watchlist, megan_gardner, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: iPhone / iPad   
OS: iOS 12   
Attachments:
Description Flags
Patch
none
Patch
none
Archive of layout-test-results from ews202 for win-future
none
Patch
thorton: review+
Patch for landing none

Description Wenson Hsieh 2019-01-06 14:12:33 PST 
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.
Comment 1 Wenson Hsieh 2019-01-06 14:13:21 PST 
<rdar://problem/45971041>
Comment 2 Wenson Hsieh 2019-01-06 18:35:25 PST 
Created attachment 358472 [details]
Patch
Comment 3 Wenson Hsieh 2019-01-06 21:23:57 PST 
Created attachment 358478 [details]
Patch
Comment 4 EWS Watchlist 2019-01-06 23:13:46 PST Comment hidden (obsolete)
Comment 5 EWS Watchlist 2019-01-06 23:13:57 PST Comment hidden (obsolete)
Comment 6 Wenson Hsieh 2019-01-07 09:09:54 PST 
Created attachment 358499 [details]
Patch
Comment 7 Tim Horton 2019-01-07 09:51:09 PST 
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 8 Wenson Hsieh 2019-01-07 09:59:01 PST 
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.
Comment 9 Wenson Hsieh 2019-01-07 10:12:46 PST 
Created attachment 358506 [details]
Patch for landing
Comment 10 WebKit Commit Bot 2019-01-07 10:50:49 PST 
Comment on attachment 358506 [details]
Patch for landing

Clearing flags on attachment: 358506

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