Bug 132974

Summary: [iOS] www.wikipedia.org is loading much slower due to FormClient::willBeginInputSession
Product: WebKit Reporter: mitz
Component: WebKit2Assignee: mitz
Status: RESOLVED FIXED    
Severity: Normal CC: enrica, jberkman
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Only call the FromClient function if the UI process will start an input session enrica: review+

Description mitz 2014-05-15 16:12:55 PDT
<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.
Comment 1 mitz 2014-05-15 16:25:42 PDT
Created attachment 231541 [details]
Only call the FromClient function if the UI process will start an input session
Comment 2 Enrica Casucci 2014-05-15 16:44:32 PDT
Comment on attachment 231541 [details]
Only call the FromClient function if the UI process will start an input session

Looks good to me.
Comment 3 mitz 2014-05-15 16:47:07 PDT
Fixed in <http://trac.webkti.org/r168916>.
Comment 4 jacob berkman 2015-03-16 17:14:40 PDT
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.
Comment 5 mitz 2015-03-16 17:18:02 PDT
(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!
Comment 6 jacob berkman 2015-03-16 17:23:35 PDT
n/p, filed bug 142757. Thanks!