Steps to reproduce: Ensure no hardware keyboard is attached. 1. Visit <http://apple.com/apple-tv-plus> 2. Tap Notify me. 3. Tap email address field to focus. 4. Tap X to close “Notify me” overlay. 5. Tap the Done button (iPhone) or keyboard dismissal button (iPad). Then keyboard stays on screen. But the keyboard should have been dismissed. Workaround: Click some editable element on the page or form field. Then you can dismiss the keyboard.
<rdar://problem/50300056>
Created attachment 372253 [details] For the Bots
Need to reduce <http://apple.com/apple-tv-plus>.
Created attachment 372262 [details] Patch
Created attachment 372268 [details] Simpler fix, but no insurance policy.... let's see what happens.
Created attachment 372374 [details] Patch
Simpler fix going into bug #198928.
Comment on attachment 372374 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=372374&action=review > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1228 > + [self _elementDidBlur]; I think the name “elementDidBlur” is a bit misleading now. When invoked from this call site, it’s more like “elementWillBlur”. But when invoked via IPC from the web process, it’s still “elementDidBlur”. Maybe we could use a more generic name. handleElementBlur? Or perhaps cleanUpAfterElementBlur?
Reduction: <!DOCTYPE html> <html> <body> <p>Tap the text field. Then tap the main page's background. Then dismiss the keyboard.</p> <iframe src="data:text/html,<input>"></iframe> </body> </html>
Comment on attachment 372374 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=372374&action=review >> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:1228 >> + [self _elementDidBlur]; > > I think the name “elementDidBlur” is a bit misleading now. When invoked from this call site, it’s more like “elementWillBlur”. But when invoked via IPC from the web process, it’s still “elementDidBlur”. > > Maybe we could use a more generic name. handleElementBlur? Or perhaps cleanUpAfterElementBlur? I hope you do not mind that I leave this for now. I could add an inline function called handleElementBlur that turns around and calls _elementDidBlur, but I don't think that improves the code much. Same for cleanUpAfterElementBlur, except that name raises more questions that it answers if I keep the implementation in _elementDidBlur. I could go another way at this and make _elementDidBlur be a one-line function that turns around and calls -cleanUpAfterElementBlur, which has the original impl. 🤷♂️. I keep thinking about this though. Maybe I add a comment above _elementDidBlur call: // Don't wait for the round-trip to clear out the focused element and hide the keyboard as the user explicitly instructed us to hide.
Wrote comment: Don't wait for WebPageProxy::blurFocusedElement() to round-trip back to us to hide the keyboard because we know that the user explicitly requested us to do so.
Created attachment 372386 [details] To land
Committed r246570: <https://trac.webkit.org/changeset/246570>
(In reply to Daniel Bates from comment #11) > Wrote comment: > > Don't wait for WebPageProxy::blurFocusedElement() to round-trip back to us > to hide the keyboard because we know that the user explicitly requested us > to do so. 👍🏻