[Webkit-unassigned] [Bug 174394] Expose way to set values of classified form controls as {Legacy WebKit, WebKit} SPI

[bugzilla-daemon at webkit.org]

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

--- Comment #10 from Frederik Riedel <riedel at apple.com> ---
Comment on attachment 315354
  --> https://bugs.webkit.org/attachment.cgi?id=315354
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=315354&action=review

>> Source/WebCore/ChangeLog:4
>> +        https://bugs.webkit.org/show_bug.cgi?id=174394
> 
> If there's a radar associated with this bug, please also include it below this bugzilla link on its own line, in the form of <rdar://problem/XXXXXXXX> (you can see https://trac.webkit.org/r219594 for an example of what this should look like).

That's <rdar://problem/31159986>

>> Source/WebKit2/ChangeLog:34
>> +        (WebKit::WebPage::setUsername): Sets the username on the HTMLInputElement.
> 
> Would it be more accurate to say something like "Sets the value of an input we've classified as a username field that is associated to the currently focused node."?
> 
> "Sets the username on the HTMLInputElement." alone doesn't really describe which HTMLInputElement this method is trying to modify.

Yeah, that's a good point!

>> Source/WebKit2/WebProcess/WebPage/ios/WebPageIOS.mm:2832
>> +        downcast<HTMLInputElement>(*m_assistedNode).setUsername(username);
> 
> Hm...instead of having the username and password fields store pointers to their associated fields, can we just compute the nextFocusableElement or previousFocusableElement on the fly when setting the username or password? I think this would make the code easier to follow (so we don't have to introduce more state to each input element which we have to then set and clean up in the right places), but has the con of an extra focusable element computation when actually setting the username or password. I don't think this is a bad tradeoff though, but it would be nice to get some more opinions about this.
> 
> Also, if we recompute the associated input elements here, then we don't have to worry about some corner cases, like the page changing a the type of an input element from a 'password' to something else (like just a 'text') after we've already classified it as a password input.

How can I compute these fields here? Right now I am using FocusController's method previousFocusableElement(*element); for this. Can I access this from here as well, or is there a different way to do it?

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