RESOLVED FIXED 196402
Get rid of HTMLInputElement::setEditingValue
https://bugs.webkit.org/show_bug.cgi?id=196402
Summary Get rid of HTMLInputElement::setEditingValue
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
Patch (19.10 KB, patch)
2019-03-29 17:40 PDT, Michael Catanzaro
darin: review+
Michael Catanzaro
Comment 1 2019-03-29 12:03:44 PDT
Michael Catanzaro
Comment 2 2019-03-29 17:40:22 PDT
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
Radar WebKit Bug Importer
Comment 9 2019-04-03 09:47:58 PDT
Note You need to log in before you can comment on or make changes to this bug.