[Webkit-unassigned] [Bug 157995] [iOS] Allow clients to override the type of an input field

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 24 11:10:11 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=157995

--- Comment #9 from Chelsea Pugh <cpugh at apple.com> ---
(In reply to comment #8)
> (In reply to comment #7)
> 
> > > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:3021
> > > +    if (NSString *textContentType = [_formInputSession textContentType])
> > > +        [_traits setTextContentType:textContentType];
> > > +    else if (NSString *textContentType = contentTypeFromFieldName(_assistedNodeInformation.autofillFieldName))
> > > +        [_traits setTextContentType:textContentType];
> > 
> > The problem with this implementation is that if the field’s
> > autofillFieldName is, say, None, and the client uses the SPI to set
> > textContentType to some non-nil value and then back to nil, the traits’
> > textContentType doesn’t revert to whatever the default value is for None. Is
> > there a way to avoid this issue?

I guess we could have an else that sets the text content type to nil (its default value). This way, if neither the input session or the autofillFieldName has something to get the textContentType from, we set it back to its original value.

> 
> I suppose this may already be a problem with the existing code when focus
> moves from a filed with an autofillFieldName that has a corresponding
> textContentType to one with an autofillFieldName that doesn’t.

I believe when we move to a new field, new a new UITextInputTraits object is created, so the textContentType would start back at nil (its default value).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160524/bcede0b3/attachment-0001.html>


More information about the webkit-unassigned mailing list