Describe the bug
On a submission form field that uses a closed vocabulary (<vocabulary closed="true">) with the onebox input type, typing text without picking a suggestion gives the user no feedback at all. The typed text is never written to the FormControl, which is correct for a closed vocabulary, but nothing marks the field as invalid or touched either, so no error message and no invalid styling appears. If the field is also required, the user only finds out the value was rejected when they try to deposit.
Two things in DsDynamicOneboxComponent.onBlur() contribute:
- when the typeahead suggestion list is open, the method calls
event.preventDefault() and event.stopImmediatePropagation() and returns without this.blur.emit(event). The error message under the field is drawn by ds-dynamic-form-control-container, which only clears its focus state when a blur event reaches it, so the message stays hidden.
- nothing ever calls
markAsTouched() or sets an error on the control for the closed vocabulary case, so even after the field is left there is no invalid state to render.
I ran into this on DSpace-CRIS 2025.02, but onBlur in dynamic-onebox.component.ts is identical on main and dspace-9_x, and markAsTouched does not appear in that file on either branch, so it should apply there too. Browser was Chrome.
To Reproduce
- Configure a submission form field with
input-type onebox, a <required> message, and <vocabulary closed="true">
- Start a submission and type some text into that field that does not match any vocabulary entry
- Wait for the suggestion list to appear, then click somewhere else on the form while it is still open
- The field shows no error message and no invalid styling. The typed text also stays in the box even though nothing was stored.
Expected behavior
Leaving a closed vocabulary field with text that was never matched to an entry should mark the field invalid and show the required error message, the same way any other required field does when it is left empty. The box should not keep showing text that was not stored.
Related work
Related to #4501 and #4502, but not the same path. Those cover the hierarchical vocabulary tree modal. This one is the typeahead suggestion list on a flat closed vocabulary, and #4502 does not add any control state handling.
We have a fix running locally against 2025.02 that flags the control and emits the blur only when a closed vocabulary violation was actually detected. Happy to open a PR against main if that direction is wanted.
Describe the bug
On a submission form field that uses a closed vocabulary (
<vocabulary closed="true">) with theoneboxinput type, typing text without picking a suggestion gives the user no feedback at all. The typed text is never written to the FormControl, which is correct for a closed vocabulary, but nothing marks the field as invalid or touched either, so no error message and no invalid styling appears. If the field is also required, the user only finds out the value was rejected when they try to deposit.Two things in
DsDynamicOneboxComponent.onBlur()contribute:event.preventDefault()andevent.stopImmediatePropagation()and returns withoutthis.blur.emit(event). The error message under the field is drawn byds-dynamic-form-control-container, which only clears its focus state when a blur event reaches it, so the message stays hidden.markAsTouched()or sets an error on the control for the closed vocabulary case, so even after the field is left there is no invalid state to render.I ran into this on DSpace-CRIS 2025.02, but
onBlurindynamic-onebox.component.tsis identical onmainanddspace-9_x, andmarkAsToucheddoes not appear in that file on either branch, so it should apply there too. Browser was Chrome.To Reproduce
input-typeonebox, a<required>message, and<vocabulary closed="true">Expected behavior
Leaving a closed vocabulary field with text that was never matched to an entry should mark the field invalid and show the required error message, the same way any other required field does when it is left empty. The box should not keep showing text that was not stored.
Related work
Related to #4501 and #4502, but not the same path. Those cover the hierarchical vocabulary tree modal. This one is the typeahead suggestion list on a flat closed vocabulary, and #4502 does not add any control state handling.
We have a fix running locally against 2025.02 that flags the control and emits the blur only when a closed vocabulary violation was actually detected. Happy to open a PR against
mainif that direction is wanted.