a_ntn
April 4, 2026, 3:56am
1
Hello Team,
I find that when using Handsontable (Angular) Autocomplete in strict mode and when allowInvalid =true, the results are inconsistent across different Handsontable versions. For example in version 16.1, I find that when I input invalid value not in the source, it accepts invalid value and cell turns red. This is as per the documentation and works as expected. But the same does not work in version 16.2, and invalid value not in the source is not accepted. I also tested the Demo example given in the Handsontable website for the section “Autocomplete strict mode”. In Demo example for version 16.1 it accepts invalid values in “Bumper color” column. But the same does not work as expected in version 16.2 Demo example, where invalid values do not stay in the cell.
Thanks
Hi @a_ntn , thank you for reporting this issue. I have confirmed that this is a bug/regression and created an issue in GitHub:
opened 03:51PM - 07 Apr 26 UTC
bug
Regression
## Description
Reported via forums: [autocomplete-strict-mode-and-allowinvalid-t… rue/9052](https://forum.handsontable.com/t/autocomplete-strict-mode-and-allowinvalid-true/9052)
In Handsontable 16.2.0, autocomplete cells with `strict: true` and `allowInvalid: true` no longer save values when the user clicks away from the editor to a different cell. Instead, the edit is silently discarded and the cell reverts to its previous value.
This is a regression from 16.1.x, where clicking away would commit the typed value (same as pressing Enter or Tab).
The bug affects **any value** committed via click-away — not just invalid values — but is most noticeable with `allowInvalid: true` because:
- Valid dropdown selections still work (the dropdown value is applied before `finishEditing`)
- Invalid values that should persist with a red `htInvalid` background are silently discarded
## Steps to reproduce
1. Create a Handsontable with an autocomplete column configured with `strict: true` and `allowInvalid: true`
2. Double-click a cell in that column to open the editor
3. Type a value not in the source list (e.g., "Purple")
4. **Click on a different cell** (do not press Enter or Tab)
**Expected (v16.1 behavior):** The typed value ("Purple") is saved. The cell displays "Purple" with a red background (`htInvalid` CSS class), and `afterValidate` fires with `isValid: false`.
**Actual (v16.2 behavior):** The typed value is discarded. The cell reverts to its previous value (e.g., "Yellow"). No validation fires for the typed value.
**Note:** If you first save an invalid value via Enter (which works), then edit it to a *new* invalid value and click away, it reverts to the first invalid value — confirming it always restores the pre-edit value, not necessarily a valid one.
## Root cause
A new `finishEditing()` override was added to `AutocompleteEditor` in v16.2.0 (PR #11873):
```js
finishEditing(restoreOriginalValue, ctrlDown, callback) {
if (this.isOpened()) {
const lastSelectedRange = this.hot.getSelectedRangeActive();
if (
isUndefined(lastSelectedRange) ||
(isDefined(lastSelectedRange) &&
!lastSelectedRange.includes(this.hot._createCellCoords(this.row, this.col)))
) {
restoreOriginalValue = true; // unconditionally discards the edit
}
}
super.finishEditing(restoreOriginalValue, ctrlDown, callback);
}
```
When the user clicks a different cell, the selection changes before `finishEditing` is called. The new code detects that the selected range no longer includes the edited cell and forces `restoreOriginalValue = true`, discarding the edit regardless of `allowInvalid` settings.
## Minimal reproduction
```html
<!DOCTYPE html>
<html>
<head>
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/handsontable@16.2.0/dist/handsontable.full.min.css">
<script src="https://cdn.jsdelivr.net/npm/handsontable@16.2.0/dist/handsontable.full.min.js"></script>
</head>
<body>
<div id="hot"></div>
<script>
new Handsontable(document.getElementById('hot'), {
data: [
{ id: 1, color: 'Yellow' },
{ id: 2, color: 'Red' },
],
columns: [
{ data: 'id', type: 'numeric', title: 'ID' },
{
data: 'color',
type: 'autocomplete',
title: 'Color',
source: ['Yellow', 'Red', 'Orange', 'Green', 'Blue'],
strict: true,
allowInvalid: true
}
],
colHeaders: true,
rowHeaders: true,
licenseKey: 'non-commercial-and-evaluation'
});
</script>
</body>
</html>
```
**To test:** Double-click a Color cell → type "Purple" → click on an ID cell. In v16.1, "Purple" persists (red). In v16.2, it reverts.
## Versions
| | Version |
|---|---|
| **Affected** | 16.2.0+ |
| **Last working** | 16.1.x |
| **Introduced by** | PR #11873 |
Thanks again for reporting it, and apologies for the delay in responding over the holiday weekend. I’ll update this thread when we have more info on a fix.