Bug 132974 – [iOS] www.wikipedia.org is loading much slower due to FormClient::willBeginInputSession

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

<rdar://problem/16844952>

The Wikipedia homepage contains an auto-focusing input element. When the element is focused, we tell the form bundle client that we’re starting a form input session, even though we don’t need to, because non-user-initiated focusing doesn’t start an input session on the UI process side.

Created attachment 231541 [details]
Only call the FromClient function if the UI process will start an input session

[Enrica Casucci]

Comment on attachment 231541 [details]
Only call the FromClient function if the UI process will start an input session

Looks good to me.

Fixed in <http://trac.webkti.org/r168916>.

[jacob berkman]

It looks like this prevents any scripts from being able to show the keyboard.

Our app embeds an html page, and has an interface similar to Keynote, in that tapping on an element presents a wireframe, and double-tapping begins editing. We handle the double-tap gesture my making a call to -[WKWebView evaluateJavaScript:completionHandler:], which ends up calling element.focus() on the appropriate node.

I suspect that setting m_userIsInteracting = true in WebPage::runJavaScriptInMainFrame() would work around this in some cases, but I'm guessing that wouldn't work if we ended up calling .focus() in a timeout handler.

Are there any other mechanisms that could be done to allow element focusing from JS? Maybe require interaction only while the page is loading or something? We've been looking forward to moving to WKWebView since last June but this behaviour has prevented us from making the switch.

(In reply to comment #4)
> It looks like this prevents any scripts from being able to show the keyboard.
> 
> Our app embeds an html page, and has an interface similar to Keynote, in
> that tapping on an element presents a wireframe, and double-tapping begins
> editing. We handle the double-tap gesture my making a call to -[WKWebView
> evaluateJavaScript:completionHandler:], which ends up calling
> element.focus() on the appropriate node.
> 
> I suspect that setting m_userIsInteracting = true in
> WebPage::runJavaScriptInMainFrame() would work around this in some cases,
> but I'm guessing that wouldn't work if we ended up calling .focus() in a
> timeout handler.
> 
> Are there any other mechanisms that could be done to allow element focusing
> from JS? Maybe require interaction only while the page is loading or
> something? We've been looking forward to moving to WKWebView since last June
> but this behaviour has prevented us from making the switch.

Commenting on this resolved bug is not a good way to raise issues with the current behavior. If there are such issues, please report a new bug. Thanks!

[jacob berkman]

n/p, filed bug 142757. Thanks!