Frontend eats changes when opening another workflow from same source as current Title: Frontend eats changes when opening another workflow from same source as current Description: ### Prerequisites - [x] I am running the latest version of ComfyUI
Test focus: Verify that loading the same workflow source again does not silently discard unsaved modifications without prompting the user or creating a new tab. Prerequisites: ComfyUI loaded with the default workflow Steps: Open the main menu → Hover over File menu → Load the default workflow to explicitly set the current workflow source → Wait for workflow to load → Double click empty canvas to open node search → Type 'Note' and press Enter to add a Note node → ...
# linux QA Video Report
- Generated at: 2026-04-13T06:41:05.220Z
- Model: `gemini-3-flash-preview`
- Target: https://github.com/Comfy-Org/ComfyUI_frontend/issues/10766
- Source video: `./qa-artifacts/qa-report-Linux-24329017512/qa-session.mp4`
- Video size: 820.9 KB
## AI Review
## Summary
The reported bug (Issue #10766) involves the frontend overwriting unsaved changes in an active workflow when the same source file is dragged into the UI, instead of opening a new tab. This allegedly results in data loss and a potential crash.
The video **does not reproduce** this bug. While the narrator claims that no new tab was opened and work was lost, the visual evidence clearly shows a new tab named **"default (2)"** being created in the ComfyUI tab bar. This behavior preserves the original "default" tab (containing the user's modifications) and opens the original file in a separate tab, which is the expected behavior to prevent data loss.
## Confirmed Issues
No issues were confirmed. The application behaved according to the expected logic described in the bug report's fix notes (opening a new tab for same-source loads).
## Possible Issues (Needs Human Verification)
### [Narration Contradicts Visuals]
`LOW` `00:26` `Confidence: High`
The narrator states "no new tab was opened" and "our changes were lost," but the video frames at `00:26` and `00:27` clearly show a second tab labeled **"default (2)"** appearing in the tab bar. The active workflow switches to this new tab (restoring the 7th node from the file), but the original **"default"** tab remains visible in the tab bar and the sidebar, suggesting the changes were not "eaten" or lost.
**Evidence:** At `00:27`, two tabs are visible: `[default]` and `[default (2)]`. The sidebar also lists both entries under "Unsaved Workflow."
**Suggested Fix:** Verify if the "default" tab still contains the modified 6-node graph. If so, the bug is fixed and the test script/narration needs updating.
## Overall Risk
`LOW`
The application appears to correctly handle the "drag-and-drop same file" scenario by creating a new tab, which is the desired behavior to avoid overwriting user work. No crashes or UI glitches were observed during the session.
## Narration
The video contains a TTS narration track:
"Step 2: We make a change — removing one node to simulate iterating on the workflow. Now 6 nodes remain. Step 3: Now we drag-drop the same file into ComfyUI again — just as we would to check the original workflow settings. Bug confirmed: the node count silently reset back to 7. No dialog appeared, no new tab was opened — our changes were lost without any warning."
## Verdict
{"verdict": "NOT_REPRODUCIBLE", "risk": "low", "confidence": "high", "narrationDetected": true}