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+

Michael Catanzaro
Reported 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.
Attachments
Patch (17.74 KB, patch)
2019-03-29 12:03 PDT, Michael Catanzaro 		no flags
DetailsFormatted DiffDiff
Patch (19.10 KB, patch)
2019-03-29 17:40 PDT, Michael Catanzaro 		darin: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 2019-03-29 12:03:44 PDT
Created attachment 366291 [details] Patch
Michael Catanzaro
Comment 2 2019-03-29 17:40:22 PDT
Created attachment 366334 [details] Patch
Michael Catanzaro
Comment 3 2019-04-01 10:06:23 PDT
Thanks for the review. I'll wait for Carlos to approve the GLib API changes before committing.
Carlos Garcia Campos
Comment 4 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.
Michael Catanzaro
Comment 5 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.)
Carlos Garcia Campos
Comment 6 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.
Michael Catanzaro
Comment 7 2019-04-03 08:01:40 PDT
*** Bug 196417 has been marked as a duplicate of this bug. ***
Michael Catanzaro
Comment 8 2019-04-03 09:42:51 PDT
Landed https://trac.webkit.org/changeset/243804/webkit
Radar WebKit Bug Importer
Comment 9 2019-04-03 09:47:58 PDT
<rdar://problem/49561363>
Note You need to log in before you can comment on or make changes to this bug.