Bug 260375

Created attachment 467320 [details] 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.