NEW190655
Caret z-index is not consistent with its input element -- appears over other elements. 
https://bugs.webkit.org/show_bug.cgi?id=190655
Summary Caret z-index is not consistent with its input element -- appears over other ...
Chet Corcos
Reported 2018-10-16 17:19:48 PDT
If I have an input that is below another div (perhaps a topbar), when I scroll my selection under the div, the caret / selection still appears above the div. I've created a demo here that you can test out on your iPhone: https://codepen.io/ccorcos/full/mzXbJB/
Attachments
Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2018-10-16 17:22:57 PDT
That's by design at the moment, but it's not great.
Chet Corcos
Comment 2 2018-10-16 19:31:49 PDT
Hmm. Well that's a bummer. Not an issue in Safari...
alxpsr
Comment 3 2019-05-23 04:40:09 PDT
That's by design? Really? Why?
Chet Corcos
Comment 4 2019-05-23 10:44:04 PDT
Can we re-design?
Wenson Hsieh
Comment 5 2019-05-23 12:29:06 PDT
(In reply to Chet Corcos from comment #4) > Can we re-design? I think "by design" (from above) was referring more to the implementation, rather than the intended user experience. Currently, our caret is rendered using native views on iOS (UIViews), rather than using web content. While this enables a whole family of platform-defined text selection and interaction gestures, it also makes it difficult to get text selection views to play well with occlusion, z-ordering, etc. In this particular example, I think we can mitigate this by allowing caret and selection views to be hosted in the view hierarchy of UIScrollViews for fast-scrollable elements (e.g. overflow scrolling containers and iframes).
Note You need to log in before you can comment on or make changes to this bug.