[WC-3613]: Rich Text keep the table configuration menu applying changes

[samuelreichert]

Pull request type

Bug fix (non-breaking change which fixes an issue)

---

Description

Jira: WC-3613

Reported on Rich Text 5.1.0, in both Inline and Class style data format. With the table configuration menu open, a new choice appears not to apply: picking "Groove" in Border Style snaps back to "Solid", and clicking another border color keeps showing the previous one. The menu stays open and looks unresponsive.

Root cause: the change itself reaches the table. Each command updates the table node, and the caret never leaves the table. What breaks is the open menu, which never refreshes:

• ConfigurationDropdown reads each control's value with section.getCurrentValue() during render, but nothing re-renders it when the document changes. It has no editor subscription.
• Its parent re-renders only on selectionUpdate, and changing a table attribute doesn't move the selection.
• The <select>s are controlled (value={currentValue}), so after onChange React puts back the stale value. That is the "chose Groove, stays Solid" in the report. The color pickers show the stale color the same way.

The first few changes can look like they work because of incidental re-renders (for example a Mendix value update or a selectionUpdate), which depend on timing.

Fix: while the menu is open, ConfigurationDropdown subscribes to the editor's transaction event and re-renders, so every control re-reads the current value. It unsubscribes when the menu closes, so there are no extra renders while closed. The cell configuration menu uses the same component and is fixed too.

Ruled out while reproducing:

• The selection leaving the table.
• The table NodeView being recreated.
• chain().focus().
• The click-outside handler.
• The toolbar keyboard model and the per-transaction re-render of the toolbar buttons (audit items BEH-09 / PERF-01).

Tests: TableConfiguration.spec.tsx renders the full widget, inserts a table, opens the table configuration menu and replays the sequence from the report: background color, border color twice, style, width twice, groove, another color. After every step it checks both the table attributes and the value each control shows, for the inline and class formats and for the cell menu. All 3 tests fail without the fix.

Based on main and independent of the other Rich Text PRs. Together with #2462 it covers the table configuration problems from the WC-3613 report.

What should be covered while testing?

1. Insert a table and open the table configuration menu.
2. Change background color, border color, border style and border width several times in a row without closing the menu. Every change shows in the menu and applies to the table.
3. Do the same with the cell configuration menu.
4. Check in both Inline and Class style data format. In Class, borders also need [WC-3613]: Rich Text class data format improvements #2462.

🤖 Generated with Claude Code

[gjulivan]

In the running app, the bug doesn't show up, even though the app is serving the unfixed code.

Why it doesn't happen in a real app:

1. Every change in the menu updates the editor, which calls handleUpdate (EditorWrapper.tsx:77).
2. The debounce helper there is created with isExecuting = false, so it calls stringAttribute.setValue() straight away, in the same click handler.
3. Mendix then re-renders the whole Rich Text widget, menu included, before the click finishes. I confirmed this in the React tree: the only component that triggers the render is pluginWidget(...), Mendix's own wrapper around the widget. Rich Text's own components don't trigger it.
4. On that re-render, getCurrentValue() reads the new editor state, so the controls show the right values.

The branch's unit test uses a mock attribute (EditableValueBuilder) whose setValue never re-renders anything. That's why the bug shows up in the test and not in Mendix.

we can close this PR.