Get rid of HTMLInputElement::setEditingValue

[Michael Catanzaro]

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.

[Michael Catanzaro]

Created attachment 366291 [details]
Patch

[Michael Catanzaro]

Created attachment 366334 [details]
Patch

[Michael Catanzaro]

Thanks for the review.

I'll wait for Carlos to approve the GLib API changes before committing.

[Carlos Garcia Campos]

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]

(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]

(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]

*** Bug 196417 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

Landed https://trac.webkit.org/changeset/243804/webkit

[Radar WebKit Bug Importer]

<rdar://problem/49561363>