Bug 142757

Summary:	calling element.focus() from -[WKWebView evaluateJavaScript:completionHandler:] does not show keyboard
Product:	WebKit	Reporter:	jacob berkman <jberkman>
Component:	WebKit API	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	cathyxz, craig, dbates, ddkilzer, developer, emiel.mols, enrica, james, jonathan, krevis, mikkel_500, mitz, nick, onderceylan, pyanfield, webkit-bug-importer, wenson_hsieh
Priority:	P2	Keywords:	InRadar
Version:	528+ (Nightly build)
Hardware:	iPhone / iPad
OS:	iOS 8.2

Description jacob berkman 2015-03-16 17:22:48 PDT

See the fix in https://bugs.webkit.org/show_bug.cgi?id=132974

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 1 David Kilzer (:ddkilzer) 2015-03-17 07:24:21 PDT

<rdar://problem/17355265>

Comment 2 Nick Quaranto 2015-05-12 17:26:02 PDT

Hey here,

We've run into this same issue with WKWebView at Basecamp (https://basecamp.com) - we'd love for this or some equivalent to UIWebView's keyboardDisplayRequiresUserAction to be added in if possible.

There doesn't seem to be any real workarounds so this really impacts our user experience when we want to focus on a web form or contenteditable element.

Comment 3 Emiel Mols 2015-09-29 06:54:37 PDT

I've managed to work-around this on at least iOS 9 by swizzling _startAssistingNode:userIsInteracting:blurPreviousNode:userObject on WKContentView and overriding the userIsInteracting value:

Pseudo code:

    swizzle_intercept("WKContentView", "_startAssistingNode:userIsInteracting:blurPreviousNode:userObject:", &hackAssist);

    void hackAssist (id self, SEL _cmd, void* arg0, BOOL arg1, BOOL arg2, id arg3) {
        ((void (*)(id,SEL,void*,BOOL,BOOL,id))swizzle_interceptee(hackAssist))(self, _cmd, arg0, TRUE, arg2, arg3);
    }

Use it to your advantage while the API doesn't change ;). Cheers!

Comment 4 pyanfield 2018-03-30 02:25:04 PDT

It's not resolved in the latest version iOS 11.

Comment 5 Kurt Revis 2022-08-15 15:45:59 PDT

I believe this was fixed in iOS 16 beta 6 by:
https://bugs.webkit.org/show_bug.cgi?id=243416