Bug 190655 - Caret z-index is not consistent with its input element -- appears over other elements.
Summary: Caret z-index is not consistent with its input element -- appears over other ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Other
Hardware: iPhone / iPad iOS 12
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-16 17:19 PDT by Chet Corcos
Modified: 2019-05-23 12:29 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chet Corcos 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/
Comment 1 Simon Fraser (smfr) 2018-10-16 17:22:57 PDT
That's by design at the moment, but it's not great.
Comment 2 Chet Corcos 2018-10-16 19:31:49 PDT
Hmm. Well that's a bummer. Not an issue in Safari...
Comment 3 alxpsr 2019-05-23 04:40:09 PDT
That's by design? Really? Why?
Comment 4 Chet Corcos 2019-05-23 10:44:04 PDT
Can we re-design?
Comment 5 Wenson Hsieh 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).