When the url 'ddg.gg' is entered with the software keyboard, the input field is auto selected, and the software keyboard reappears. This does not happen when picking the url from favorites.
I've seen this now and again as well. Just a wild stab... • Safari preemptively begins loading URL while it is being typed. • Script on the page focuses the field. • User hits enter, and Safari makes the web view first responder. The keyboard then appears, since we're becoming FR with a focused element.
Created attachment 367062 [details] Patch
IIRC, this activity state change logic was added in <https://trac.webkit.org/changeset/226480/webkit> to (IIRC) support password AutoFill for apps on iOS.
Comment on attachment 367062 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367062&action=review > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4965 > + if (changingActivityState && [UIKeyboard isInHardwareKeyboardMode]) > + return YES; > + It seems this is equivalent to just moving the `changingActivityState` check above to the #if PLATFORM(WATCHOS) section (since we return YES anyways if [UIKeyboard isInHardwareKeyboardMode] is YES)
(In reply to Wenson Hsieh from comment #3) > IIRC, this activity state change logic was added in > <https://trac.webkit.org/changeset/226480/webkit> to (IIRC) support password > AutoFill for apps on iOS. Ah, I see. This patch will possibly break having focused restored when re-launching WKWebView. What activity state changes are relevant in this case?
Created attachment 367142 [details] Patch
(In reply to Wenson Hsieh from comment #4) > Comment on attachment 367062 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=367062&action=review > > > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4965 > > + if (changingActivityState && [UIKeyboard isInHardwareKeyboardMode]) > > + return YES; > > + > > It seems this is equivalent to just moving the `changingActivityState` check > above to the #if PLATFORM(WATCHOS) section (since we return YES anyways if > [UIKeyboard isInHardwareKeyboardMode] is YES) I updated the patch to send the changing activity flag bitfield to the UI process, and then use the bitfield to determine if the software keyboard should be shown. I believe this will avoid breaking the fix in https://trac.webkit.org/changeset/226480/webkit. Thanks for reviewing!
rdar://problem/48970509
Comment on attachment 367142 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367142&action=review So, I added chagingActivityState originally to make it so that the software keyboard would not be dismissed if you backgrounded Safari, and then brought it forward again. That is the activityState that was changing. I have noted that this has problems when you background a page that has an auto-focused element that has not brought up the keyboard because there has been no user interaction. If you background that page, and bring it forward, the keyboard shows up. Sending the whole bitfield across seems like a good way to make sure that we're only showing the keyboard in the right cases, but at the risk of bikesheding, if you're going to change the type of this flag, please make the name more appropriate as well, Just 'activityState' should be good. > Source/WebKit/UIProcess/WebPageProxy.h:348 > RefPtr<API::Object> userData; Please change to activityState, since this is no longer a bool. > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4968 > + if (changingActivityState != WebCore::ActivityState::IsFocused && changingActivityState) I think this would read better if the order was switched. > Source/WebKit/WebProcess/WebPage/WebPage.h:1760 > Init this with something appropriate if possible.
(In reply to Megan Gardner from comment #9) > Comment on attachment 367142 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=367142&action=review > > So, I added chagingActivityState originally to make it so that the software > keyboard would not be dismissed if you backgrounded Safari, and then brought > it forward again. That is the activityState that was changing. I have noted > that this has problems when you background a page that has an auto-focused > element that has not brought up the keyboard because there has been no user > interaction. If you background that page, and bring it forward, the keyboard > shows up. Sending the whole bitfield across seems like a good way to make > sure that we're only showing the keyboard in the right cases, but at the > risk of bikesheding, if you're going to change the type of this flag, please > make the name more appropriate as well, Just 'activityState' should be good. > > > Source/WebKit/UIProcess/WebPageProxy.h:348 > > RefPtr<API::Object> userData; > > Please change to activityState, since this is no longer a bool. > > > Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:4968 > > + if (changingActivityState != WebCore::ActivityState::IsFocused && changingActivityState) > > I think this would read better if the order was switched. > > > Source/WebKit/WebProcess/WebPage/WebPage.h:1760 > > > > Init this with something appropriate if possible. Thanks for reviewing! I will update the patch.
Created attachment 368046 [details] Patch
Comment on attachment 368046 [details] Patch Clearing flags on attachment: 368046 Committed r244559: <https://trac.webkit.org/changeset/244559>