QA Session Recordings
Issue #10766 reports
Frontend eats changes when opening another workflow from same source as currentTitle: 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 default workflow while the current default workflow has unsaved changes does not discard those changes without warning.
Prerequisites: ComfyUI is loaded with the default workflow
Steps: Wait for the default workflow to fully load → Click on the first CLIP Text Encode node to select it → Delete the selected node to modify the workflow and trigger the dirty state → Take a screenshot to verify the workflow is modified → Open the ComfyUI main hamburger menu → Hover over the File menu to open the submenu → ...
Prerequisites: ComfyUI is loaded with the default workflow
Steps: Wait for the default workflow to fully load → Click on the first CLIP Text Encode node to select it → Delete the selected node to modify the workflow and trigger the dirty state → Take a screenshot to verify the workflow is modified → Open the ComfyUI main hamburger menu → Hover over the File menu to open the submenu → ...
AI Comparative Review
# linux QA Video Report
- Generated at: 2026-04-01T14:13:52.967Z
- Model: `gemini-3-flash-preview`
- Target: https://github.com/Comfy-Org/ComfyUI_frontend/issues/10766
- Source video: `./qa-artifacts/qa-report-Linux-23852131414/qa-session.mp4`
- Video size: 580.2 KB
## AI Review
## Summary
The video successfully reproduces Issue #10766. The user loads a workflow, makes a modification, and then drags the same workflow file into the browser again. The application silently overwrites the modified state with the original file content without opening a new tab or prompting the user, resulting in data loss.
## Confirmed Issues
### Unsaved changes overwritten when re-dragging same workflow file
`HIGH` `00:09` `Confidence: High`
When a workflow file that is already active is dragged into the editor, the application discards local changes and resets the current tab to the file's state on disk. It fails to open a new tab as expected for a new file load.
**Evidence:**
1. At `00:04`, the workflow "input_order_swap" is loaded. A "String" node contains the value "foo".
2. At `00:08`, the user edits the "String" node value, changing "foo" to "bar".
3. At `00:09`, a file is dropped into the interface. The value "bar" immediately reverts to "foo", and no additional tab is created in the top navigation bar.
**Suggested Fix:** Update the `file_drop` logic to follow the same path as the `file_button` (fixed in PR #7104), ensuring a new tab with a unique suffix is created, or implement a dirty-state check to prevent silent data loss.
---
## Possible Issues (Needs Human Verification)
- **Crash reporting:** The original issue report mentioned "Crashes ComfyUI completely". In the video, the UI remains responsive after the overwrite, so a hard crash was not observed, though functional data loss occurred.
## Overall Risk
**High**. This bug leads to immediate and silent data loss (work being "eaten") when a user attempts to reference an original workflow by dragging it back into the interface.
## Verdict
{"verdict": "REPRODUCED", "risk": "high", "confidence": "high"}