Bug 190655
| Summary: | Caret z-index is not consistent with its input element -- appears over other elements. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Chet Corcos <ccorcos> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Major | CC: | alxpsr, bfulgham, simon.fraser, wenson_hsieh, zalan |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | iPhone / iPad | ||
| OS: | iOS 12 | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=190786 | ||
Chet Corcos
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)
That's by design at the moment, but it's not great.
Chet Corcos
Hmm. Well that's a bummer. Not an issue in Safari...
alxpsr
That's by design? Really? Why?
Chet Corcos
Can we re-design?
Wenson Hsieh
(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).