Programmatic input into a text field doesn't update the binding

[antony]

Describe the bug
Can't quite figure out if this is desirable behaviour or not (and I couldn't find a previous issue for it), but it looks like when you paste into (or use Javascript to set the value of) a bound field, the binding does not get updated.

This is troublesome when considering a login field where a password-store like 1Password or LastPass or Chrome Autofill is used.

To Reproduce
I've reproduced the issue here.

https://svelte.dev/repl/85e2b7097e8f4255b0fc5757988ebdb9?version=3.16.4

Expected behavior
I expect changing a field's value to update any bindings it has.

Information about your Svelte project:

• Svelte any including 3.16.4

Severity
I can work around it, it's more of a problem for "doing the most obvious thing".

[Conduitry]

Two-way bindings are listening for the input event on the element, which isn't emitted when you manually set the element's .value, so I'd say that part is expected.

Pasting into a field (using the OS's actual, proper 'paste' operation) is updating the binding for me, presumably because the browser knows to emit the input event.

Autofill is another thing though. Some years ago, I was involved with a project (written in AngularJS 1) that had to jump through some hoops to get the app to see autofilled values. It feels like the nicest way for this to be handled would be for these plugins to trigger manual input events, but that's obviously a really big ask for some large established projects.

I'm not sure what other frameworks do today. Are there events they can listen to to know when autofill stuff has happened? Do they use shitty setInterval polling? Is the rest of the world just enabling these plugins to do what they want and update .value without triggering an input?

[antony]

I'm trying to work around it now using an action and I'm finding some other interesting things which prevent my workaround.

Looks like the paste event isn't fired by some plugins, and the change event is only fired if it was a manual change and then a javascript change - the second javascript change is never seen.

I also can't set the seen value from my event handler. That might be another issue...

[vipero07]

I've seen many websites where they have a disabled login button that only enables when there is data entered into a field and when used with a password manager it doesn't update forcing me, as the user, to click into a field thus enabling the button. So I have a feeling either this isn't generally handled by some libraries or a few software engineers don't bother to fix this issue (or don't recognize it as an issue).

Personally I think this may be more of a bug with the password managers, because even if svelte has some built in workaround (like setInterval polling as @Conduitry mentioned) there are plenty of other websites where this isn't handled.

There is a pseudo class applied to an element that has been autofilled in webkit browsers :-webkit-autofill this obviously doesn't account for any other browsers and doesn't fix any setInterval sillyness.

[antony]

I actually got this to work in the end, and the issue was in fact elsewhere in my login page, so whatever (at least lastpass) does works for Svelte.

I will test with 1Password when I have access to a Mac or Windows machine, but I expect that will work too.

I guess this leaves me undecided on whether I'm wrong in expecting a JavaScript (programmatic) field value change to update the binding. Considering that I actually use (abuse?) the fact that it doesn't for my autofill location fields, where I set a "display value" without triggering any actual binding changes, I'm going to suggest that the current behaviour is desirable...

But I'm stuck. Does anybody have any strong feeling either way? I'm eager to close the issue if the current behaviour seems reasonable.

Lets just have a poll:

[ayZagen]

Is there any workaround for this ?

[antony]

@ayZagen just update the bound value when you change the input programatically. For example: https://svelte.dev/repl/85e2b7097e8f4255b0fc5757988ebdb9?version=3.20.1

The overwhelming number of votes signal that the current behaviour is desirable.

[ayZagen]

Thanks for quick reply. But there is not any way to catch the browser autocomplete event as far as I know.

[antony]

@ayZagen I had the same issue with browser auto-completion. I think I did one of:

bind to on:change or on:paste or on:update - one of these is triggered I believe. You can find more detail here https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/input_event