Repository navigation
create layout: a container's RenderMode is silently dropped; check and exec pass #1582
Description
Summary
create or modify layout accepts RenderMode on a container, and check and exec both pass, but the value isn't stored. The container keeps the default render mode (div). alter layout … set refuses the property.
Repro
mdl 1;
create or modify layout Mod.L_Test (
layouttype: 'Responsive'
) {
scrollcontainer layoutContainer {
region center {
container ctnMain (RenderMode: 'Main', Class: 'app-main') {
placeholder Main
}
}
}
};
check reports Check passed! and exec reports Created layout Mod.L_Test. describe layout Mod.L_Test then prints:
container ctnMain (Class: 'app-main') {
Expected
Forms$DivContainer.RenderMode is written, so a layout can render <main>, <nav> and <header> landmarks. Failing that, check rejects the property instead of dropping it in silence.
Workaround
Add ARIA roles from a theme JavaScript file loaded through a custom theme/web/index.html.
Tested with: mxcli nightly-20261018-80b1b8d0d (also seen on v0.26.0), Mendix 11.12.5, macOS arm64.
Activity
github-actions commentedon Oct 19, 2026
Issue Triage
Summary:
The
create or modify layoutcommand silently ignores a container’sRenderModeproperty, even thoughcheckandexecreport success.Checklist for bug report completeness
mxcli nightly-20261018-80b1b8d0d(also seen on v0.26.0)RenderMode: 'Main'Forms$DivContainer.RenderModeshould be stored, allowing<main>,<nav>,<header>landmarkscheckandexecsucceed, butdescribe layoutshows theRenderModemissing; container stays as defaultdivMissing information:
Please provide the output of
mxcli diag --bundle(or at least the relevant session log) so we can inspect the internal processing and confirm where the property is being dropped.Thank you for reporting this issue! Once we have the diagnostic bundle, we’ll be able to investigate further.
Automated triage via OpenRouter — workflow source