DMN rules can not be reordered

[timstawowski]

Describe the bug

Dragging a DMN rule to change its order does not work.

dmn_rule_order_bug.mov

Steps to reproduce

1. create a Camunda 7 or 8 DMN file
2. create at least two rules and add an input value to one of the columns
3. try to change the rule order via drag+drop

Expected behavior

Changing the rule order should be possible as it was in earlier modeler versions.

Environment

• OS: MacOS 26.6.2 (25G83)
• Camunda Modeler Version: 5.51.0
• Execution Platform: Camunda 7, Camunda 8
• Installed plug-ins: token-simulator, Camunda Property Infos, Transaction Boundaries

Additional context

No response

[barmac]

Thanks for reporting. The first version where I could reproduce it is 5.45.

[barmac]

🤖 Automated root-cause analysis (reviewed by a human before posting)

I dug into this and the regression isn't in dmn-js/table-js — dmn-js's row/col drag-and-drop logic still works correctly even when a cell holds a FEEL value (verified by dispatching real dragstart/dragover/drop events against a live decision table with populated cells; the row reorder went through as expected).

The actual regression is in camunda-modeler itself: 75b4819f "fix: enable edit shortcuts in nested inputs" (closing #5306), first released in 5.45.0 — matching @barmac's bisect above.

In client/src/shared/ui/trap/KeyboardInteractionTrap.js that fix changed:

window.addEventListener('focus', this.handleFocus);
// →
window.addEventListener('focusin', this.handleFocus);

focus doesn't bubble, so the old window-level listener almost never fired for focus changes happening deep in the page. focusin bubbles, so now every focus change anywhere in the app fires handleFocus, which calls triggerAction('update-menu', ...) → App.updateMenu (debounced 50ms) → AppParent.handleMenuUpdate → an IPC sendMenuUpdate call that has the Electron main process rebuild the native application menu (Menu.setApplicationMenu).

Why this specifically breaks DMN row drag-and-drop:

• DMN decision-table cells that hold a value are rendered as contenteditable <div> FEEL editors, not <input>/<textarea>.
• Typing a value into a cell leaves real browser focus inside it.
• Grabbing the row's drag handle blurs that cell, firing a focusin/focusout cycle, which schedules the native-menu rebuild ~50ms later.
• Rebuilding the native macOS menu bar while an HTML5 drag session is in progress interrupts/cancels that drag session — a known macOS/Electron interaction, since native drag sessions run inside a special event-tracking run loop that menu invalidation disrupts.
• A table where no cell has ever been focused never triggers this focus-shift, so dragging still works — matching the reported repro condition ("add an input value to one of the columns").

This means the dmn-js version bump between 5.44 and 5.45 is a coincidental correlate, not the cause.

Suggested fix direction: guard the menu update so it doesn't fire (or doesn't reach the native menu rebuild) while a native drag-and-drop is in progress, or skip the IPC round-trip when the computed enabled state hasn't actually changed since the last update.

[barmac]

🤖 Correction to the above (reviewed by a human before posting)

My first analysis was wrong — after writing an e2e test that drives a real native HTML5 drag (via Playwright, dispatching genuine mouse events rather than synthetic DOM events), the row reorder failed even with completely empty cells, which ruled out the focus/menu-rebuild theory entirely. KeyboardInteractionTrap.js is not involved.

The actual root cause is in client/src/app/drop-zone/DropHandler.js. This is the app-wide drop zone used to let users open a diagram by dragging a file onto the window — it wraps the editor area, so every native drop event happening anywhere inside it (including inside a nested dmn-js decision table) reaches it first.

handleDragOver and handleDragLeave both guard themselves correctly:

handleDragOver(event) {
  if (!this.isDragAllowed(event)) {
    return DropHandler.STATES.NOT_DRAGGING;
  }
  event.preventDefault();
  event.stopPropagation();
  ...
}

isDragAllowed checks whether the dragged dataTransfer.items actually look like a droppable file. For dmn-js's internal row/col drag (started via dataTransfer.setData('text', '__DUMMY') in table-js), this correctly returns false, so those two handlers step out of the way and the event proceeds to dmn-js's own document-level dragover/dragleave listener.

handleDrop, however, is missing that same guard:

async handleDrop(event) {
  event.preventDefault();
  event.stopPropagation();   // <-- always, regardless of isDragAllowed()
  ...
}

So on drop, this always calls stopPropagation() — even for the internal DMN drag — which prevents the event from ever reaching table-js's own document-level drop listener (bound in table-js's DragAndDrop.js). The row/col highlight (dragover) still shows correctly during the drag since dragover isn't blocked, which is why the drag looks like it's working right up until you let go — but the actual reorder command (modeling.moveRow/moveCol) never fires, because the drop event dies at the drop zone.

This explains the reported behavior fully and doesn't depend on a cell holding a value at all (that detail in the original repro was incidental, not the trigger) — reordering rows or columns in any embedded dmn-js (or bpmn-js) decision table/diagram is broken by this whenever it sits inside this drop zone, which matches "regressed in 5.45" as a coincidental timing correlation rather than a causal one — I haven't yet pinned down exactly which change introduced the drop zone's missing guard, but the fix is independent of that.

Fix: mirror the same isDragAllowed(event) guard in handleDrop that already exists in handleDragOver/handleDragLeave, so a non-file drop is left alone and bubbles on to whatever nested handler (dmn-js, bpmn-js, …) is actually meant to receive it.

I have a fix (with an e2e test reproducing the exact scenario, plus a unit test on DropZone) ready and will follow up with a PR.

[barmac]

🤖 (human-reviewed) Follow-up on the version boundary: found the specific commit that made this regression appear exactly between 5.44 and 5.45.

The underlying code defect — DropHandler#handleDrop (the app-wide file-drop zone) missing a guard its sibling methods have — has actually been present since 2f320ff8 (Sep 2024, v5.29.0), but it was harmless until 7b284466c — "deps: update to react@18", first released in v5.45.0.

That commit switched client/src/index.js from React 16's ReactDOM.render(<App/>, rootElement) to React 18's createRoot(rootElement).render(<App/>). This changes where React attaches its own native event listener for a bubbling event like drop:

• React 16 (through 5.44.0): the listener sits on document — the same node table-js (dmn-js's decision table library) binds its own row/column drag-and-drop drop listener to. Multiple listeners on the same node all fire regardless of order, so DropHandler's (buggy, unconditional) stopPropagation() call didn't actually block table-js's listener from also running — dragging worked.
• React 18 with createRoot (from 5.45.0): the listener moves to the app's own root container element, which sits below document in the tree. Now the drop event hits React's listener (and DropHandler's stopPropagation()) before it can reach document, so table-js's listener never sees it — the row/column reorder command never fires, even though the drag-over highlight still looks correct throughout the gesture.

The fix (adding the missing guard back to handleDrop) is posted as PR #6168 and doesn't depend on this timeline — it's correct regardless of which React root API is active — but this explains precisely why it surfaced exactly at that version boundary.