`mxcli check` passes, `exec` fails: native listview design properties are unwritable (false green)

[MendixMau]

Summary

A native (non-pluggable) listview's design properties — Remove empty text,
Remove loadmore button, Reset list style — cannot be written by ALTER PAGE. Both available
routes pass mxcli check --references cleanly and then fail at mxcli exec.

This is reported primarily as a detection gap. The syntax check is not merely unhelpful here;
it actively asserts the operation is valid. An agent that trusts check will draft the script,
report it validated, and only discover the truth when it mutates a real model.

Reproduction

On any page containing a native listview whose DesignProperties include 'Remove empty text':

Route 1 — set the property directly

alter page <Module>.<Page> {
  set 'Remove empty text' = off on <listviewName>
};

• mxcli check <script> -p <model>.mpr --references → Check passed!
• mxcli exec <script> -p <model>.mpr → fails:
  failed to set Remove empty text on <listviewName>: property "Remove empty text" not found (widget has no pluggable Object)

Route 2 — restate the widget

alter page <Module>.<Page> {
  replace <listviewName> with { ...subtree without the property... }
};

• mxcli check ... --references → Check passed!
• mxcli exec ... → fails: htmlelement, attribute and tagcontentcontainer reported as
  not a widget in this project [MDL-WIDGET25].

Route 2's failure is the sharper one: those three keywords are exactly what describe page
emits for that subtree on the unmodified model. So describe page produces output that
create/replace will not accept — the round-trip is not closed for pages containing an
HTMLElement.

Cause

Native listview design properties live in Forms$Appearance.DesignProperties. The SET path
looks for a pluggable widget's Object.Properties and finds nothing to write. The check stage
does not distinguish the two storage locations, so it validates the name against neither.

Suggested fixes, ranked

1. Close the false green. Make check resolve a design-property name against the widget's
   actual storage location and fail at check time when the widget is native. A check that cannot
   tell should say so rather than pass.
2. Implement the write for Forms$Appearance.DesignProperties on native widgets.
3. Close the describe/create round-trip for htmlelement / attribute /
   tagcontentcontainer, so replace remains a usable fallback.
4. Failing all three, have exec name the workaround in its error text: this property is only
   reachable from Studio Pro.

How to retest

Run both routes above. Route 1 is fixed when check fails with a clear message, or exec
succeeds. Route 2 is fixed when a describe page of a page containing an htmlelement can be fed
back through replace without MDL-WIDGET25.

---

---

Found on Mendix 11.12.2. Both routes were tested on a disposable scratch copy of a model, never a
real one. A CSS-class workaround covers the inner listview (ALTER PAGE ... SET Class writes
fine); only the design property itself is blocked.

[github-actions]

Issue Triage

Summary:
The user reports that mxcli check incorrectly validates attempts to modify native listview design properties, but mxcli exec later fails because those properties cannot be written.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version	❌	Not mentioned
Mendix version	✅	Mendix 11.12.2
Scenario (what was tried)	✅	Using ALTER PAGE … SET … or replace on a native listview’s design properties
Expected output	✅	Property should be set (or check should reject the invalid operation)
Experienced output	✅	check passes, then exec fails with “property not found” or “not a widget” errors
AI bug report (mxcli diag --bundle or session log)	❌	Not provided

What’s missing:

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

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

---

Automated triage via OpenRouter — workflow source