fix(layout): cap visible toasts at 5 to bound the toast-root column #121
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
psa-systems/bunyip!121
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/cap-toast-stack-at-5"
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?
Closes BUNYIP-98.
window.bunyipToastappended every pill into#bunyip-toast-rootwith no cap on visible children. Each pill auto-dismissed after 2.5s, but a tight loop (the canonical case: spamming "Copy" on/downloads) piled them up indefinitely - 50 quick clicks could fill the viewport vertically.Cap-and-evict, single while loop in front of the append:
while (root.children.length >= 5) {
root.removeChild(root.firstChild);
}
5 is the visible-pill target. The oldest is evicted so the newest action always lands, which is the signal users most want feedback for. The existing auto-dismiss
setTimeoutchain is untouched and already guards onpill.parentNode, so a manually evicted pill does not double-remove.No new state, no queue, no dedup. The previous "spam-fills-screen" attempts at dedup-by-message are deferred until someone reports a case the cap alone does not address.
just check-containerclean (modulo the pre-existingtest_config_defaultsparallel-env-var flake on main; 188 other tests pass; fmt + clippy + build clean).#BUNYIP-98
Closes BUNYIP-98. `window.bunyipToast` appended every pill into `#bunyip-toast-root` with no cap on visible children. Each pill auto-dismissed after 2.5s, but a tight loop (the canonical case: spamming "Copy" on `/downloads`) piled them up indefinitely - 50 quick clicks could fill the viewport vertically. Cap-and-evict, single while loop in front of the append: while (root.children.length >= 5) { root.removeChild(root.firstChild); } 5 is the visible-pill target. The oldest is evicted so the newest action always lands, which is the signal users most want feedback for. The existing auto-dismiss `setTimeout` chain is untouched and already guards on `pill.parentNode`, so a manually evicted pill does not double-remove. No new state, no queue, no dedup. The previous "spam-fills-screen" attempts at dedup-by-message are deferred until someone reports a case the cap alone does not address. `just check-container` clean (modulo the pre-existing `test_config_defaults` parallel-env-var flake on main; 188 other tests pass; fmt + clippy + build clean). #BUNYIP-98