Combobox input event only fires on dropdown selection change #2053
Replies: 4 comments 1 reply
-
|
I'm also experiencing this issue. I expected Here's a minimal reproduction that demonstrates the problem: View Source<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>wa-combobox: input/change events don't fire when typing</title>
<script
src="https://kit.webawesome.com/507d22d96b844fe5.js"
crossorigin="anonymous"
></script>
</head>
<body style="padding: 2em">
<h1>wa-combobox event bug</h1>
<ol>
<li>Type "Orange" in the box → no input/change events fire</li>
<li>Select "Apple" from dropdown → change event fires</li>
</ol>
<wa-combobox id="combo" allow-custom-value placeholder="Type or select...">
<wa-option value="Apple">Apple</wa-option>
<wa-option value="Banana">Banana</wa-option>
<wa-option value="Cherry">Cherry</wa-option>
</wa-combobox>
<div id="log" style="margin-top: 1em; padding: 1em; background: #f5f5f5; border: 1px solid #ccc; font-family: monospace; font-size: 14px;"></div>
<script>
const combo = document.getElementById("combo");
const log = document.getElementById("log");
function addLog(message) {
const time = new Date().toLocaleTimeString();
log.innerHTML += `[${time}] ${message}<br>`;
}
combo.addEventListener("input", (e) => {
addLog(`input event fired, value: "${e.target.value}"`);
});
combo.addEventListener("change", (e) => {
addLog(`change event fired, value: "${e.target.value}"`);
});
combo.addEventListener("blur", (e) => {
addLog(`blur event fired, value: "${e.target.value}"`);
});
addLog("Event listeners attached. Try typing a custom value.");
</script>
</body>
</html> |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. The combobox currently dispatches That said, it sounds like a separate event might be useful that indicates when the user types something into the internal text field — even if that doesn't change the combobox's value or count as "input". Do you folks think an additional event would work for this? I'm reluctant to overload the existing events because they're designed to work how they do and additional dispatches would create noise for folks using them as they exist today. |
Beta Was this translation helpful? Give feedback.
-
|
I don’t really feel equipped to suggest whether adding new events or overloading existing ones is the right direction. I don’t have much insight into the tradeoffs on the implementation side. What I can do is explain my expectations and needs as a user. My expectation going in was that A new event would of course solve this for me. That said, I think that adding more events can be confusing, and I’m not sure the distinction between the internal text field and the combobox value is very intuitive from a user perspective. They are just someone who picks it up as a single component. Also, since the component is marked as experimental, it feels like concerns about adding noise for users who rely on the current behavior may be less critical at this stage. |
Beta Was this translation helpful? Give feedback.
-
|
Fair points. The ~90% use case is aimed at folks declaratively adding options and users selecting from them. I'll work on improving the custom values API and adding a better example. |
Beta Was this translation helpful? Give feedback.
-
|
I'm in agreement with @emilbonnek on this one - not fully understanding the impact of a new vs existing event, I'd defer to you on the right path forward. But I also second the expected behavior going in was that it functioned more or less like a wa-input, with the added benefit of a dropdown to help guide my users, where the input event would fire whenever they supplied a value - typing, pasting, or selecting from the dropdown. That way we can easily handle one/two-way bindings and consume/react to user-supplied data. A new event type would work, but may be a bit confusing for users who are already binding other form elements through the input event. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
The combobox input event does not fire when a user types a value. It appears to function the same as the change event and only fires when a dropdown value is selected. Expected behavior (at least how I am trying to use it) would be the same as the wa-input component, the event would fire as keyboard inputs is received. Especially when the "allow-custom-value" attribute is used, although could be useful across the board.
To Reproduce
Steps to reproduce the behavior:
I'm using Vue and the shorthand input attribute directly on the component (works fine on wa-inputs), but have observed the same behavior with document.addeventlistener.
Beta Was this translation helpful? Give feedback.
All reactions