fix: combobox 'input' event doesn't give the correct text value when input changes

[caseyfaber]

🐛 Bug Report

If you listen to the input event on fast-combobox, it doesn't give the correct text value for event.target.value.

💻 Repro or Code Sample

This example is logging event.target.value to the console on input changes: https://jsfiddle.net/Lg56ptrm/

1. Type "test" in the input. It logs a blank string for every letter.
2. Click away from the combobox.
3. Click back in the input and type some more. Now it logs the string "test".
4. Open the dropdown and select an option.
5. Erase the input and type "test" again. Now it logs the text of the last option selected.

🤔 Expected Behavior

It should give the current value typed in the input box.

😯 Current Behavior

It gives the value in the input box when last losing focus.

🌍 Your Environment

• OS & Device: Windows 10
• Browser: Chrome
• Version: fast-foundation 2.27.1

[claviska]

@chrisdholt does your team have any bandwidth to look into this one? If not, I'll see if we can make some time to help out.

[chrisdholt]

@chrisdholt does your team have any bandwidth to look into this one? If not, I'll see if we can make some time to help out.

If you have some bandwidth we would definitely welcome a contribution here. @radium-v as FYI since he's been deeply involved with the combobox work. Thanks @claviska, let us know if you want to pick this up!

[claviska]

Looking at this more, I'm not sure it is a bug. The docs only show a change event coming from combobox, not an input event.

The change event is emitting the correct value. The input event, which is the one in question, is being retargeted to the host element from the internal <input>. That means event.target will be the host element, not the internal input. As a result, the code in the fiddle is where the bug actually is.

In short, we're listening for an input event that comes from the internal input, but then we're checking the value of the target, which is the host element, and that value is correctly unchanged.

We can easily work around this, though.

https://jsfiddle.net/h8ryzn0v/

The difference between the original and the new fiddle is this line:

combobox.addEventListener('input', event => {
  console.log(event.target.control.value);
});

The control property of the host element points to the internal input, so this provides the correct value.

So this isn't technically a bug, but can we convert it to a feature request? It would be much more ergonomic to prevent the internal input event and emit one from the combobox with the correct value.