9 hours ago
hi everyone
Firmware: LM5p2-KCDZ, 20251204
Visu version: new Visu (2025.11)
Browser: Safari on iOS (also reproduced via LM Home app, same engine)
ISSUE
A Category containing 7 native "thermostat" type widgets (tile_width=2,
tile_height=2 each) renders with large empty vertical gaps between rows
on iPhone, both in portrait and on first load. Widgets are present in
the DOM (confirmed via remote Web Inspector — all 7 elements have
display:block, visibility:visible, correct getBoundingClientRect()),
but visually appear scattered with huge blank spaces between them.
The same Category with simple "switch" type widgets (lights, in the
same Visu, same device) renders perfectly with no gaps.
WORKAROUND FOUND
Rotating the device screen once (portrait -> landscape -> portrait,
or just to landscape) immediately fixes the layout — all widgets
snap into a correct, gap-free grid.
DIAGNOSIS
This strongly suggests a Muuri grid layout calculation race condition:
the thermostat widget's internal SVG (circular arc, +/- buttons) takes
longer to reach final rendered dimensions than a simple switch icon.
If Muuri's initial layout() call measures widget dimensions before the
SVG has settled, it computes wrong absolute positions (translateX/
translateY) for those items, leaving gaps. A manual resize event
(screen rotation) forces Muuri to recalculate using final dimensions.
ATTEMPTED WORKAROUND (did not work)
Tried dispatching window.dispatchEvent(new Event('resize')) via
custom JS at multiple delays after page load (600ms/1200ms/2000ms/
3500ms) to replicate the rotation effect. This did NOT fix the issue —
suggesting Muuri's internal layout recalculation is not triggered by
the generic window resize event, but by something else (ResizeObserver
on the container, or an internal viewport-change handler specific to
orientation change).
QUESTIONS
1. Is this a known issue with the thermostat widget (or any widget
with internal SVG) in tile view on narrow viewports?
2. Is there a way to programmatically trigger Muuri's layout() /
refreshItems() from custom JS, since the Muuri instance isn't
exposed on window?
3. Is there a recommended fix (CSS containment, explicit width/height
constraints, etc.) to prevent this race condition?
Happy to share screenshots, exported widget JSON and console output
if useful for reproduction.
Ctrl+F5 already tried, no effect (this isn't a cache issue — confirmed
via fresh hard reload).
Firmware: LM5p2-KCDZ, 20251204
Visu version: new Visu (2025.11)
Browser: Safari on iOS (also reproduced via LM Home app, same engine)
ISSUE
A Category containing 7 native "thermostat" type widgets (tile_width=2,
tile_height=2 each) renders with large empty vertical gaps between rows
on iPhone, both in portrait and on first load. Widgets are present in
the DOM (confirmed via remote Web Inspector — all 7 elements have
display:block, visibility:visible, correct getBoundingClientRect()),
but visually appear scattered with huge blank spaces between them.
The same Category with simple "switch" type widgets (lights, in the
same Visu, same device) renders perfectly with no gaps.
WORKAROUND FOUND
Rotating the device screen once (portrait -> landscape -> portrait,
or just to landscape) immediately fixes the layout — all widgets
snap into a correct, gap-free grid.
DIAGNOSIS
This strongly suggests a Muuri grid layout calculation race condition:
the thermostat widget's internal SVG (circular arc, +/- buttons) takes
longer to reach final rendered dimensions than a simple switch icon.
If Muuri's initial layout() call measures widget dimensions before the
SVG has settled, it computes wrong absolute positions (translateX/
translateY) for those items, leaving gaps. A manual resize event
(screen rotation) forces Muuri to recalculate using final dimensions.
ATTEMPTED WORKAROUND (did not work)
Tried dispatching window.dispatchEvent(new Event('resize')) via
custom JS at multiple delays after page load (600ms/1200ms/2000ms/
3500ms) to replicate the rotation effect. This did NOT fix the issue —
suggesting Muuri's internal layout recalculation is not triggered by
the generic window resize event, but by something else (ResizeObserver
on the container, or an internal viewport-change handler specific to
orientation change).
QUESTIONS
1. Is this a known issue with the thermostat widget (or any widget
with internal SVG) in tile view on narrow viewports?
2. Is there a way to programmatically trigger Muuri's layout() /
refreshItems() from custom JS, since the Muuri instance isn't
exposed on window?
3. Is there a recommended fix (CSS containment, explicit width/height
constraints, etc.) to prevent this race condition?
Happy to share screenshots, exported widget JSON and console output
if useful for reproduction.
Ctrl+F5 already tried, no effect (this isn't a cache issue — confirmed
via fresh hard reload).
