[Webkit-unassigned] [Bug 260375] New: WKWebView produces overlays when focusing text inputs

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Aug 17 21:14:02 PDT 2023


            Bug ID: 260375
           Summary: WKWebView produces overlays when focusing text inputs
           Product: WebKit
           Version: Safari 17
          Hardware: Mac (Apple Silicon)
                OS: macOS 13
            Status: NEW
          Severity: Major
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: teodor.atroshenko at gmail.com

Created attachment 467320

  --> https://bugs.webkit.org/attachment.cgi?id=467320&action=review

Screenshot from macOS running on Apple Silicon showing both overlays at once

When running an iOS app on macOS device running on Apple Silicon, focusing any text input fields (<input type=text />, <textarea>, <div contenteditable>) inside WKWebView causes two things to happen:

- On first click, 90% of the time, a bar will appear at the bottom of the app window. The bar has some transparency to it and appears to be related to Virtual Keyboard, even though no virtual keyboard is actually shown or needed - the device has a physical keyboard attached. Upon losing focus of the text input field, the bar hides itself 100% of the times. Both show and hide are done with smooth sliding animation. The value of env(safe-area-inset-bottom) remains unchanged and this bar overlays the content on the page. The Visual Viewport also doesn't appear to get activated - there is no way to scroll the resultant (reduced) viewport.

- While already focused inside the input field with the bottom bar either showing or not showing (roughly 10% of attempts), left-clicking (aka "default clicking" with Magic Mouse) inside the same text input field causes a new kind of overlay box to appear. This box is drawn immediately underneath the input field, but it contains no elements - just a plain box with rounded corners a couple hundred pixels in height. Removing focus from the input field does not dismiss the overlay - it stays there permanently until the app is closed.

Further observations and remote tests on a user device revealed that the second overlay container does not appear to belong to the app rendering context - this was discovered by screen-sharing just the app window, the first bottom bar overlay shows up on the captured video stream, while the floating overlay does not.

Screenshot attached. Arrow labeled (1) points to first overlay and arrow labeled (2) points to the second overlay described above.

The lack of ability to dismiss the second overlay makes this issue impacting to end users.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230818/9744ca5d/attachment.htm>

More information about the webkit-unassigned mailing list