You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* This is getting triggered twice. Trap and exit.
647
+
* Claude explanation: Not DOM event bubbling — Handsontable's hook system is internal, entirely separate from the DOM event system. The double-fire is caused by Handsontable's own plugin system re-triggering the selection hook as a side effect of the work done inside the handler.
648
+
649
+
The causal chain:
650
+
1. User clicks a cell → Handsontable fires afterSelectionEnd
651
+
2. Handler detects a row change → calls crudCalculateDependentKeys
652
+
3. That leads (through refreshTabDisplay) to tabFilter on dependent DH instances
653
+
4. tabFilter calls, in sequence:
654
+
- filtersPlugin.clearConditions() — clears any active filter conditions
655
+
- hiddenRowsPlugin.showRows(shown) / hideRows(hidden) — changes the visible row set
656
+
- dh.hot.resumeExecution() — flushes all queued plugin operations at once
657
+
- dh.render() — redraws the table
658
+
The resumeExecution() flush is what causes it. When Handsontable flushes queued operations after hiding/showing rows, it internally re-validates and re-applies the current selection
659
+
to account for the fact that visual row indices may have shifted. That re-validation fires afterSelectionEnd again on the same instance with identical coordinates — same row, column,row2, column2.
660
+
The suspendExecution() / resumeExecution() pattern is recommended by Handsontable for batching plugin operations, but it comes with the side effect that the selection hooks can re-fire during the flush. It is specifically not the filtersPlugin.clearConditions() call alone, nor the hide/show calls alone — it's the combination flushed together via
661
+
resumeExecution().
662
+
663
+
The deduplication guard in the handler (current_selection coordinate comparison → early return) is the correct way to handle this. It's a well-known Handsontable quirk with the
0 commit comments