[webkit-reviews] review granted: [Bug 193180] Native caret shows up alongside the page's caret when requesting desktop site on jsfiddle.net : [Attachment 358499] Patch

[bugzilla-daemon at webkit.org]

Tim Horton <thorton at apple.com> has granted Wenson Hsieh
<wenson_hsieh at apple.com>'s request for review:
Bug 193180: Native caret shows up alongside the page's caret when requesting
desktop site on jsfiddle.net
https://bugs.webkit.org/show_bug.cgi?id=193180

Attachment 358499: Patch

https://bugs.webkit.org/attachment.cgi?id=358499&action=review




--- Comment #7 from Tim Horton <thorton at apple.com> ---
Comment on attachment 358499
  --> https://bugs.webkit.org/attachment.cgi?id=358499
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.