<b-form-input> becoming out of sync with value if using formatter

[kalvenschraut]

When a form-input has a formatter on it stripping out characters in the case of trying to only allowing numerial values in a text input, the input value can sometimes not match up with the emitted value.

codepen: https://codepen.io/Kalvens/pen/Lqabrj (type any nonnumerical character in the input)
browser: Chrome Version 69.0.3497.100 (Official Build) (64-bit)
OS: linux

I believe the issue comes from

bootstrap-vue/src/mixins/form-text.js

Lines 107 to 123 in a14245c

	updateValue(value) {
	value = this.stringifyValue(value)
	if (this.localValue !== value) {
	// keep the input set to the value before modifiers
	this.localValue = value
	if (this.number) {
	// Emulate .number modifier behaviour
	const num = parseFloat(value)
	value = isNaN(num) ? value : num
	} else if (this.trim) {
	// Emulate .trim modifier behaviour
	value = value.trim()
	}
	// Update the v-model
	this.$emit('update', value)
	}
	},

the value is already formatted at that point so if the formatter strips out all of the characters leaving the value to be an empty string, nothing will happen even though the input still has a value set for it

I was playing around with your source code and doing

if (this.localValue !== value) {
    ...
} else if (this.$el.value !== value)  {
  this.$el.value = value;
}

seems to fix my issue, but I am not sure if that would be affecting anything else using the mixin.

[tmorehouse]

Is this occurring on a browser that supports autocomplete or predictive text?

There is an issue with how some browsers handle these features. Some emit and I put for every character, while others will wait and emit a change once an autocomplete is completed or a space is entered (and inpput event may or may not be emitted with the change.

[kalvenschraut]

I am using chrome 69 right now, but I am typing into the input without using any autocomplete. The updateValue function is being fired correctly on key press.

The localValue could potentially not be different then the value passed into updateValue due to the formatter function. If that is the case the input's value needs to be updated to match the localValue/value param so they stay in sync.

[jacobmllr95]

@tmorehouse I've looked into this a bit and I don't know why the input's value isn't changed.

[kalvenschraut]

@tmorehouse is my proposed fixed as outlined earlier not what you guys are want to do? I see you added a test that seems to be similar to this issue at

bootstrap-vue/src/components/form-input/form-input.spec.js

Lines 483 to 501 in ec91788

	it('does not update value when non-lazy formatter returns false', async () => {
	const wrapper = mount(Input, {
	propsData: {
	value: 'abc',
	formatter(value) {
	return false
	}
	},
	attachToDocument: true
	})
	const input = wrapper.find('input')
	input.element.value = 'TEST'
	input.trigger('input')
	expect(wrapper.emitted('input')).not.toBeDefined()
	expect(wrapper.emitted('update')).not.toBeDefined()
	// value in input should remain the same as entered
	expect(input.element.value).toEqual('TEST')
	expect(wrapper.vm.localValue).toBe('abc')
	})

Where it is asserting that the value TEST is still set as the input value. Although I am not sure if that is something you are specifically handling for when formatters return false. My issue is mainly coming from when my formatter is returning an empty string, which I think should force the input's value to also be an empty string and not to keep any characters the user may have typed into the input.

[tmorehouse]

Yeah, there may need to be a few tweaks to the formatter. Lazy formatting works best (as it doesn't cause issues with cursor positioning while the user types... even google libphonenumber has dropped as you type formatting).

Typically, one could use the non lazy formatter to prevent certain characters to be type, by preventing default on the passed input event (although change events are not preventable), and then returning false so that the v-model isn't updated.

[skourismanolis]

I just want to point out that this bug did not exist on version 2.0.0-rc.12, I updated from that yesterday and it broke, so I'm not exactly sure what version change caused it.