m/paliad
1
0
Fork 0
Code Issues 152 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Dashboard widgets overlap on mixed-size rows (1-col + 2-col next to each other) #70

New Issue
Open
opened 2026-05-21 08:38:04 +00:00 by mAi · 2 comments
mAi commented 2026-05-21 08:38:04 +00:00
Collaborator
Copy Link

Trigger

m 2026-05-21 10:37:

the dashboard manager got better but it is possible that one widget overlaps the other (one wide 2 column, 1 only 1 column). That needs fixing.

What's wrong

After the dashboard overhaul in m/paliad#69 (pasteur, merged at f8c6206), widgets can visually overlap when they share a row at different column-spans — e.g. a 2-col-wide widget next to a 1-col widget where the layout's grid-coordinates don't account for the wider one's footprint.

Likely root causes (to verify in code):

  • The grid-recalculation step computes occupancy per column but ignores colspan > 1 cells, leaving the next column 'free' even though the wider widget covers it.
  • Drop-target hit detection allows landing a 1-col widget on a cell that's the right-half of an existing 2-col widget.
  • Reflow on resize doesn't bump siblings when the resized widget grows into their cells.

Acceptance

  • Placing a 1-col widget adjacent to a 2-col widget: no visual overlap, both render fully in their declared bounds.
  • Resizing a 1-col widget to 2-col: if the new col is occupied, sibling either shifts or the resize is rejected with a hint (design call — recommended (R): shift sibling to next available cell).
  • Drag-drop drop-target excludes cells occupied by another widget's colspan footprint.
  • Reload preserves the conflict-free layout.

Continuity note

m asked the worker handling this be kept persistent for follow-ups (vs. fired-on-completion). Stay parked on branch after merge so the next dashboard-tweak ping has warm context.

Role

fixer — focused grid-occupancy bug; small-to-medium PR depending on whether the conflict resolution path (shift siblings vs reject) is implemented in this PR or deferred.

## Trigger m 2026-05-21 10:37: > the dashboard manager got better but it is possible that one widget overlaps the other (one wide 2 column, 1 only 1 column). That needs fixing. ## What's wrong After the dashboard overhaul in m/paliad#69 (pasteur, merged at `f8c6206`), widgets can visually overlap when they share a row at different column-spans — e.g. a 2-col-wide widget next to a 1-col widget where the layout's grid-coordinates don't account for the wider one's footprint. Likely root causes (to verify in code): - The grid-recalculation step computes occupancy per column but ignores `colspan > 1` cells, leaving the next column 'free' even though the wider widget covers it. - Drop-target hit detection allows landing a 1-col widget on a cell that's the right-half of an existing 2-col widget. - Reflow on resize doesn't bump siblings when the resized widget grows into their cells. ## Acceptance - Placing a 1-col widget adjacent to a 2-col widget: no visual overlap, both render fully in their declared bounds. - Resizing a 1-col widget to 2-col: if the new col is occupied, sibling either shifts or the resize is rejected with a hint (design call — recommended (R): shift sibling to next available cell). - Drag-drop drop-target excludes cells occupied by another widget's colspan footprint. - Reload preserves the conflict-free layout. ## Continuity note m asked the worker handling this be kept persistent for follow-ups (vs. fired-on-completion). Stay parked on branch after merge so the next dashboard-tweak ping has warm context. ## Role **fixer** — focused grid-occupancy bug; small-to-medium PR depending on whether the conflict resolution path (shift siblings vs reject) is implemented in this PR or deferred.
mAi self-assigned this 2026-05-21 08:38:04 +00:00
mAi commented 2026-05-21 08:48:53 +00:00
Author
Collaborator
Copy Link

Fixed in commit 92d0340d7409ee481818186f5cf48f91e2cb8941 — PR #71.

Root cause: computePlacements in frontend/src/client/dashboard.ts trusted explicit (x, y) without checking the colspan footprint of already-placed widgets, so a drag-drop swap with mismatched widths or a resize-grow into a sibling produced overlapping cells.

Fix: extracted placement math into pure ./dashboard-grid.ts with an occupancy bitmap. Collisions are now resolved by scanning downward from the requested row for the first free w×h block (preferring the requested column). x+w overflow is clamped instead of rendered. 14 regression tests cover the mixed-width swap, resize-grow sibling shift, multi-row widgets, and the overflow clamp.

Worker stays parked on mai/tesla/dashboard-overlap for follow-up tweaks.

Fixed in commit [92d0340d7409ee481818186f5cf48f91e2cb8941](https://mgit.msbls.de/m/paliad/commit/92d0340d7409ee481818186f5cf48f91e2cb8941) — PR #71. Root cause: `computePlacements` in `frontend/src/client/dashboard.ts` trusted explicit (x, y) without checking the colspan footprint of already-placed widgets, so a drag-drop swap with mismatched widths or a resize-grow into a sibling produced overlapping cells. Fix: extracted placement math into pure `./dashboard-grid.ts` with an occupancy bitmap. Collisions are now resolved by scanning downward from the requested row for the first free w×h block (preferring the requested column). x+w overflow is clamped instead of rendered. 14 regression tests cover the mixed-width swap, resize-grow sibling shift, multi-row widgets, and the overflow clamp. Worker stays parked on `mai/tesla/dashboard-overlap` for follow-up tweaks.
mAi commented 2026-05-21 08:49:46 +00:00
Author
Collaborator
Copy Link

Shipped via tesla; merged at https://mgit.msbls.de/m/paliad/commit/875d0c1. Live after Dokploy deploy.

Shipped via tesla; merged at https://mgit.msbls.de/m/paliad/commit/875d0c1. Live after Dokploy deploy.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#70
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?