Bug 196402

Summary: Get rid of HTMLInputElement::setEditingValue
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: FormsAssignee: Michael Catanzaro <mcatanzaro>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cdumez, cgarcia, darin, mcatanzaro, webkit-bug-importer, wenson_hsieh, zalan
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: PC   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=195708
https://bugs.webkit.org/show_bug.cgi?id=196417
Attachments:
Description Flags
Patch
none
Patch darin: review+

Description Michael Catanzaro 2019-03-29 11:54:26 PDT
HTMLInputElement::setEditingValue is only used for Epiphany password autofill. We did it this way because that's what Chrome uses for autofill, but Apple uses HTMLInputElement::setValueForUser. Let's switch to that instead, then we can get rid of setEditingValue.

This fixes logging into ting.com after username and password are autofilled by Epiphany. Before this change, the login would fail unless you first manually edit either the username or the password field.
Comment 1 Michael Catanzaro 2019-03-29 12:03:44 PDT
Created attachment 366291 [details]
Patch
Comment 2 Michael Catanzaro 2019-03-29 17:40:22 PDT
Created attachment 366334 [details]
Patch
Comment 3 Michael Catanzaro 2019-04-01 10:06:23 PDT
Thanks for the review.

I'll wait for Carlos to approve the GLib API changes before committing.
Comment 4 Carlos Garcia Campos 2019-04-01 22:39:06 PDT
Comment on attachment 366334 [details]
Patch

I don't understand why we have to add new function and deprecate the old one, we could simply change the existing function to use setValueForUser and applications won't have to do anything.
Comment 5 Michael Catanzaro 2019-04-02 06:01:40 PDT
(In reply to Carlos Garcia Campos from comment #4)
> I don't understand why we have to add new function and deprecate the old
> one, we could simply change the existing function to use setValueForUser and
> applications won't have to do anything.

Of course we don't have to. It's totally optional. Exposing set_value_for_user() is really just a nicer name. If you don't want it, I'll remove it and not deprecate anything.

Applications don't have to do anything either way, because I did change the existing function to use setValueForUser. (But to avoid the deprecation warning they would need to change to the new name, of course.)
Comment 6 Carlos Garcia Campos 2019-04-03 00:57:11 PDT
(In reply to Michael Catanzaro from comment #5)
> (In reply to Carlos Garcia Campos from comment #4)
> > I don't understand why we have to add new function and deprecate the old
> > one, we could simply change the existing function to use setValueForUser and
> > applications won't have to do anything.
> 
> Of course we don't have to. It's totally optional. Exposing
> set_value_for_user() is really just a nicer name. If you don't want it, I'll
> remove it and not deprecate anything.
> 
> Applications don't have to do anything either way, because I did change the
> existing function to use setValueForUser. (But to avoid the deprecation
> warning they would need to change to the new name, of course.)

I think it's easier to avoid the new method.
Comment 7 Michael Catanzaro 2019-04-03 08:01:40 PDT
*** Bug 196417 has been marked as a duplicate of this bug. ***
Comment 8 Michael Catanzaro 2019-04-03 09:42:51 PDT
Landed https://trac.webkit.org/changeset/243804/webkit
Comment 9 Radar WebKit Bug Importer 2019-04-03 09:47:58 PDT
<rdar://problem/49561363>