Web frame: delete leaves the iframe DOM overlay orphaned in the page #104
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_whiteboard#104
Loading…
Add table
Add a link
Reference in a new issue
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?
Summary
Deleting a webframe leaves the iframe DOM overlay (
<div id="wf-overlay-<id>">) orphaned in the page. On the receiver side, the Konva placeholder disappears but the iframe stays floating on the canvas. On the originator, the same orphaning happens but the visible effect depends on whether the wrapper happens to be hidden at the moment of delete.Steps to reproduce
Local
#wf-overlay-<id>).Remote
Expected
The iframe overlay is removed from the DOM whenever the webframe is deleted — locally or via a remote
object.deletedbroadcast.Actual
The Konva group is destroyed but the iframe
<div>is leaked.Root cause
WhiteboardWebframe.destroyOverlay(id)exists and is exported, but neither call site invokes it on delete:WhiteboardObjects.deleteObject(id)(inobjects.js) destroysobj.groupbut doesn't dispatch type-specific cleanup.msg.type === 'object.deleted'handler insync.jsdestroysobj.groupbut doesn't dispatch either.Suggested fix
In both call sites, when
obj.type === 'webframe', callWhiteboardWebframe.destroyOverlay(id)BEFOREobj.group.destroy(). Guard withtypeof WhiteboardWebframe !== 'undefined' && WhiteboardWebframe.destroyOverlayfor defensive consistency with the rest of the codebase.If other types acquire DOM overlays in the future (e.g. video frames), consider a small
_typeCleanupmap inobjects.jskeyed by type → cleanup fn, called from a single_destroyTyped(obj, id)helper. Out of scope for this issue — direct call is fine for now.Acceptance criteria
<div>.object.deletedbroadcast) removes both on the receiver.Spec — Issue #104: Webframe delete must also remove the iframe DOM overlay
Objective
On every delete path (local user delete and remote
object.deletedbroadcast), destroy the iframe DOM overlay along with the Konva group. Currently both paths leak the<div id="wf-overlay-<id>">.Root cause
WhiteboardWebframe.destroyOverlay(id)is exported but never called from the delete paths:WhiteboardObjects.deleteObject(id)inobjects.jsdestroysobj.groupand skips type-specific cleanup.sync.jsmsg.type === 'object.deleted'handler does the same on the receiver.Files to Modify
crates/hero_whiteboard_ui/static/web/js/whiteboard/objects.js— add a webframe-specific cleanup indeleteObject.crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.js— add the same cleanup in theobject.deletedhandler.Step-by-Step Plan
Step 1 —
objects.js::deleteObjectBefore
obj.group.destroy(), add:Step 2 —
sync.jsobject.deletedhandlerBefore the existing
obj.group.destroy()call (which currently runs after the frame-cleanup loop added in #96), add the symmetric block:Acceptance Criteria
<div id="wf-overlay-<id>">from the DOM.Notes
destroyOverlayis idempotent on missing ids — already guards onoverlays[id]lookup.remapOverlay(tempId, serverId)) is unaffected; remap moves the entry to a new key butdestroyOverlaylooks up the current id, so deletes after remap still hit it.Test Results
Implementation Summary
Two files changed, +6/-0. Adds
WhiteboardWebframe.destroyOverlay(id)to both delete paths so the iframe<div>no longer leaks.crates/hero_whiteboard_ui/static/web/js/whiteboard/objects.jsIn
deleteObject(id), beforeobj.group.destroy():crates/hero_whiteboard_ui/static/web/js/whiteboard/sync.jsIn the
object.deletedhandler, mirrored: beforeobj.group.destroy()on the receiver:Verification
cargo fmt --all -- --check: cleancargo check --workspace: cleancargo clippy --workspace -- -D warnings: cleannode --checkonobjects.jsandsync.js: cleanManual smoke test
<div>are removed (verify via DevTools thatwf-overlay-<id>is gone).Notes
destroyOverlayis already idempotent (guards onoverlays[id]).remapOverlaymoves the entry to the new server id, anddestroyOverlaylooks up the current id, so deletes after remap still hit it.