Widget property conditional visibility from editorConfig.js (CE0463 on VideoPlayer + Timeline)

[ako]

Two CE0463 cases on Mendix 11.9 trace to the same architectural gap: the BSON serializer has no per-property visibility metadata.

Symptoms

Run mx check on mx-test-projects/test5-app/test5.mpr (Mendix 11.9.0):

[error] [CE0463] "The definition of this widget has changed..." at Timeline 'timelineCustom1'
[error] [CE0463] "The definition of this widget has changed..." at Video Player 'video1'

Page	Widget	What we emit	What Studio Pro's "Update widget" produces
PW.P_PW02_Properties	VideoPlayer video1 (type: 'expression')	Populated empty Forms$ClientTemplate on videoUrl + posterUrl	null (hidden when type='expression')
PW.P_PW08_MultiSlot	Timeline timelineCustom1 (customVisualization: true)	null on title / description / timeIndication	Populated empty Forms$ClientTemplate (always visible)

Reference baselines: P_PW02_Properties_2 and P_PW08_MultiSlot_2 in the same project — Studio Pro–updated copies that pass mx check cleanly.

Root cause

Property visibility for pluggable widgets isn't declared in widget.xml — it lives in editorConfig.js as imperative JavaScript calling Mendix's hidePropertyIn / hidePropertiesIn / hideNestedPropertiesIn helpers. Example from VideoPlayer's compiled editorConfig.js:

exports.getProperties = function (e, t, r) {
  "dynamic"   === e.type       && F.hidePropertiesIn(t, e, ["urlExpression", "posterExpression"]);
  "expression" === e.type      && F.hidePropertiesIn(t, e, ["videoUrl", "posterUrl"]);
  "aspectRatio" === e.heightUnit
    ? F.hidePropertyIn(t, e, "height")
    : F.hidePropertyIn(t, e, "heightAspectRatio");
  ...
};

mxcli's serializer has no visibility into this, so it emits the embedded template's defaults regardless of the widget's active configuration. Two specific call sites:

• sdk/mpr/writer_widgets_custom.go:229 — serializeWidgetValueForRawType hardcodes TextTemplate: nil (Timeline's under-population)
• The RawType clone path that preserves the embedded template's populated ClientTemplate as-is (VideoPlayer's over-population)

Proposed fix

See docs/11-proposals/PROPOSAL_widget_property_visibility.md (committed in 0ad1b753) for the full design. Summary:

1. Extend .def.json with a propertyVisibility[] field expressing simple eq / ne / truthy / falsy / and / or conditions.
2. Static-analyze editorConfig.js during mxcli widget init to populate it (pattern-match the three known helpers; fall back to "unsupported" for non-equality rules).
3. At serialization time, evaluate each rule against the widget's current property values to decide TextTemplate: null vs populated ClientTemplate.

Phasing

• Phase 1 — hand-author rules for VideoPlayer + Timeline and wire the serializer through. Closes both CE0463 cases above.
• Phase 2 — build the JS extractor and regenerate propertyVisibility[] for all embedded definitions.
• Phase 3 — extend to hideNestedPropertiesIn (Accordion groups, DataGrid columns).

Phase 1 alone fixes the immediate symptom.

Related

• CE0463 on engine-routed pluggable widgets (Accordion, Maps, PopupMenu, AreaChart) #548 — CE0463 sequence on object-list items (4ea402c2) — same TextTemplate-null pattern, but only for object-list paths.
• docs/03-development/WIDGET_BSON_VERSION_COMPATIBILITY.md — broader CE0463 patch ledger; this issue belongs to that family.

[github-actions]

Issue Triage

Summary:
The issue reports that mx check produces CE0463 errors for VideoPlayer and Timeline widgets in a Mendix 11.9 project because mxcli’s BSON serializer lacks visibility into property‑visibility logic defined in editorConfig.js.

Checklist of required bug‑report information

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	✅	Mendix 11.9.0 (stated)
Scenario (what the user was trying to do)	✅	Running mx check on the test project
Expected output	✅	No CE0463 errors (Studio Pro‑updated copies pass)
Experienced output	✅	CE0463 errors at Timeline timelineCustom1 and VideoPlayer video1
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing

• The exact version of mxcli you used (output of mxcli --version or commit/build identifier).
• A diagnostic bundle or at least the session log from mxcli diag --bundle to help reproduce the environment.

Could you please add those details? Once we have them, we’ll be able to investigate the problem more effectively. Thank you for the thorough description!

---

Automated triage via OpenRouter — workflow source