Bug 184844 – Clients implementing _webView:focusShouldStartInputSession: can't easily express the "default" behavior

• Component: Forms
• Status: RESOLVED FIXED

[Paul Knight]

If a client doesn't implement -[_WKInputDelegate's _webView:focusShouldStartInputSession:], there's a sophisticated default behavior that reads something like "Assist the form node if the gesture was user driven or they keyboard is already active or drag and drop is performing a drop action".

This rule can't really be reimplemented by the client, so a client can't allow programmatic focus in some circumstances but use the default behavior otherwise.

[Radar WebKit Bug Importer]

<rdar://problem/39610958>

[Paul Knight]

Created attachment 338539 [details]
Patch

[Paul Knight]

One thing I'm not sure about is how to go about marking -_webView:focusShouldStartInputSession: as deprecated. Should we do it now, or only once _webView:decidePolicyForFocusedElement: ships?

[Wenson Hsieh]

(In reply to Paul Knight from comment #3)
> One thing I'm not sure about is how to go about marking
> -_webView:focusShouldStartInputSession: as deprecated. Should we do it now,
> or only once _webView:decidePolicyForFocusedElement: ships?

I think we could do it as a followup, before new SPI ships. Luckily, there only appears to be one other internal client aside from Safari that uses -_webView:focusShouldStartInputSession:, so it should be simple to reach out to them and get them to adopt the new SPI before we mark the old one as deprecated.

This looks reasonable to me! Perhaps the names could be tweaked a bit (I considered -decidePolicyForStartingInputSessionWithFocusedElement:, but that seemed a bit verbose). Adding a couple more WK2 owners to get more opinions...

Comment on attachment 338539 [details]
Patch

For something where there’s a default behavior and a way to customize it, subclassing is usually nicer than delegation—you can just call super, if you want, see “what would have happened”, and then customize the behavior.

[Paul Knight]

What would you subclass in this case?

(In reply to Paul Knight from comment #6)
> What would you subclass in this case?

WKWebView. Specifically in this case, one can envision

@interface WKWebView
- (BOOL)focusShouldStartInputSession:(id <_WKFocusedElementInfo>)info;
@end

with a client’s WKWebView subclass override doing something like

- (BOOL)focusShouldStartInputSession:(id <_WKFocusedElementInfo>)info
{
    if ([super focusShouldStartInputSession:info])
        return YES;
    if (/* something special is going on */)
        return YES;
    return NO;
}

[Paul Knight]

Th(In reply to mitz from comment #7)
> (In reply to Paul Knight from comment #6)
> > What would you subclass in this case?
> 
> WKWebView. Specifically in this case, one can envision
> 
> @interface WKWebView
> - (BOOL)focusShouldStartInputSession:(id <_WKFocusedElementInfo>)info;
> @end

This is a really good thought, and I'm not sure how to square it with some of the other existing _WKInputDelegate methods. A client that overrides focusShouldStartInputSession may also be interested in the input session that then starts, possibly splitting its logic into different places.

Maybe we can pursue the subclass hook as this transitions to API, for example as part of bug 142757?

[Wenson Hsieh]

(In reply to mitz from comment #7)
> (In reply to Paul Knight from comment #6)
> > What would you subclass in this case?
> 
> WKWebView. Specifically in this case, one can envision
> 
> @interface WKWebView
> - (BOOL)focusShouldStartInputSession:(id <_WKFocusedElementInfo>)info;
> @end
> 
> with a client’s WKWebView subclass override doing something like
> 
> - (BOOL)focusShouldStartInputSession:(id <_WKFocusedElementInfo>)info
> {
>     if ([super focusShouldStartInputSession:info])
>         return YES;
>     if (/* something special is going on */)
>         return YES;
>     return NO;
> }

Good point! I think this is definitely something to consider when we address <rdar://problem/17355265>. Paul brought up the point that for the client adopting this SPI, it makes the input session customization story less cohesive if some of the input delegate hooks are on the WKWebView, and others are on the _WKInputDelegate.

Perhaps the line in the sand is whether or not we have an input session yet? So we have a subclass-able hook on WKWebView prior to starting the input session, and then _WKInputDelegate would then handle logic related to input sessions (maybe we should then rename it to WKInputSessionDelegate).

[WebKit Commit Bot]

Comment on attachment 338539 [details]
Patch

Clearing flags on attachment: 338539

Committed r230902: <https://trac.webkit.org/changeset/230902>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.