Open vursen opened 2 months ago
For ComboBox there are use-cases where this is useful: https://github.com/vaadin/flow-components/issues/6442#issuecomment-2238584840. So basically as an auto-complete where you don't want to add custom values to the list of options.
For ComboBox there are use-cases where this is useful: #6442 (comment). So basically as an auto-complete where you don't want to add custom values to the list of options.
When custom values are explicitly allowed, I would see this as a valid behaviour. But without, I would also rather expect the CB to not allow setting a "custom" value on the server side. Or with other words, it should allow the same input programmatically, that is allowed from the user.
See also #1546
The multi CB also has this problem. It feels even more "present" due to its displayment as chips.
Description
Some components like Select, RadioButtonGroup, CheckboxGroup (and possibly ComboBox), allow setting values that aren't in the data provider and then getting them back through
getValue()
. After being set, these values are only available on the server, while the web component keeps the previous valid value. Each of these components also has a test that relies on this behavior, for example:https://github.com/vaadin/flow-components/blob/eb6b138a9681b27b1c95dc8da8a4f51aeeae0931/vaadin-select-flow-parent/vaadin-select-flow/src/test/java/com/vaadin/flow/component/select/SelectTest.java#L791-L807
Expected outcome
The tests assert behavior that shouldn't be supported because it leads to an inconsistent state between server and client and thus is misleading. When trying to set such a value, the component should either throw an exception or revert it and log a warning.
Minimal reproducible example
You can observe the issue in the mentioned test.
Additional context
This issue is why https://github.com/vaadin/flow/pull/19310 had to be reverted despite being a correct solution.
Environment
Vaadin version(s): 24.5 and earlier OS: Mac OS
Browsers
No response