Bug 132974 - [iOS] www.wikipedia.org is loading much slower due to FormClient::willBeginInputSession
Summary: [iOS] www.wikipedia.org is loading much slower due to FormClient::willBeginIn...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: mitz
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-05-15 16:12 PDT by mitz
Modified: 2015-03-16 17:23 PDT (History)
2 users (show)

See Also:


Attachments
Only call the FromClient function if the UI process will start an input session (2.25 KB, patch)
2014-05-15 16:25 PDT, mitz
enrica: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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!