WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
198922
REGRESSION (
r240757
): Cannot dismiss the keyboard on
http://apple.com/apple-tv-plus
https://bugs.webkit.org/show_bug.cgi?id=198922
Summary
REGRESSION (r240757): Cannot dismiss the keyboard on http://apple.com/apple-t...
Daniel Bates
Reported
2019-06-17 10:24:00 PDT
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.
Attachments
For the Bots
(2.00 KB, patch)
2019-06-17 10:26 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch
(3.62 KB, patch)
2019-06-17 12:06 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Simpler fix, but no insurance policy.... let's see what happens.
(1.07 KB, patch)
2019-06-17 13:39 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch
(8.86 KB, patch)
2019-06-18 13:29 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
To land
(9.08 KB, patch)
2019-06-18 14:49 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2019-06-17 10:24:12 PDT
<
rdar://problem/50300056
>
Daniel Bates
Comment 2
2019-06-17 10:26:53 PDT
Created
attachment 372253
[details]
For the Bots
Daniel Bates
Comment 3
2019-06-17 12:06:08 PDT
Need to reduce <
http://apple.com/apple-tv-plus
>.
Daniel Bates
Comment 4
2019-06-17 12:06:39 PDT
Created
attachment 372262
[details]
Patch
Daniel Bates
Comment 5
2019-06-17 13:39:37 PDT
Created
attachment 372268
[details]
Simpler fix, but no insurance policy.... let's see what happens.
Daniel Bates
Comment 6
2019-06-18 13:29:44 PDT
Created
attachment 372374
[details]
Patch
Daniel Bates
Comment 7
2019-06-18 13:32:24 PDT
Simpler fix going into
bug #198928
.
Wenson Hsieh
Comment 8
2019-06-18 13:34:28 PDT
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?
Daniel Bates
Comment 9
2019-06-18 13:35:33 PDT
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>
Daniel Bates
Comment 10
2019-06-18 14:44:12 PDT
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.
Daniel Bates
Comment 11
2019-06-18 14:47:35 PDT
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.
Daniel Bates
Comment 12
2019-06-18 14:49:39 PDT
Created
attachment 372386
[details]
To land
Daniel Bates
Comment 13
2019-06-18 14:50:27 PDT
Committed
r246570
: <
https://trac.webkit.org/changeset/246570
>
Wenson Hsieh
Comment 14
2019-06-18 15:29:17 PDT
(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.
👍🏻
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug