Bug description
Reframe uses FFmpeg.wasm in single-threaded mode. When a user clicks Export, the WASM module runs a synchronous, CPU-bound video processing pipeline entirely on the main JavaScript thread. The browser tab becomes completely unresponsive — no interaction, no cancel button, no live progress that actually reflects real processing state — until FFmpeg finishes or the browser kills the tab.
Steps to reproduce
Steps to reproduce the behavior:
1.Upload a large video (500MB+), change aspect ratio to 9:16, set speed to 2×, and click Export
2.Observe: the progress bar shows a percentage, but the tab is completely frozen — no scrolling, no UI interaction possible
-
Try clicking "Cancel" or navigating away — the tab does not respond until FFmpeg yields
-
On a mid-range laptop or phone, the browser may show "Page Unresponsive" and offer to kill the tab
-
If the tab is killed, all processing progress is lost with no recovery path — user must start over
Expected behavior
FFmpeg processing should run in a Web Worker (or via the multi-threaded @ffmpeg/ffmpeg build with SharedArrayBuffer), completely off the main thread. The UI should remain fully interactive during export. A real-time progress bar should receive messages from the worker via postMessage. A functional "Cancel" button should terminate the worker and clean up memory. If the browser tab is closed or refreshed mid-export, the user should receive a warning ("Export in progress — are you sure you want to leave?") via the beforeunload event.
Actual behavior
FFmpeg.wasm runs in single-threaded mode on the main browser thread. The entire tab freezes for the full duration of the export. The displayed progress bar likely reflects FFmpeg's internal log callbacks, but the UI itself cannot update, animate, or respond to user input while processing is active. There is no cancel mechanism — even if a cancel button exists, it cannot be triggered because the thread is blocked. On lower-end devices, the browser triggers an "Aw, Snap!" or "Page Unresponsive" crash dialog. For the app's stated 2GB file limit, this is not an edge case — it is the primary use case.
Bug description
Reframe uses FFmpeg.wasm in single-threaded mode. When a user clicks Export, the WASM module runs a synchronous, CPU-bound video processing pipeline entirely on the main JavaScript thread. The browser tab becomes completely unresponsive — no interaction, no cancel button, no live progress that actually reflects real processing state — until FFmpeg finishes or the browser kills the tab.
Steps to reproduce
Steps to reproduce the behavior:
1.Upload a large video (500MB+), change aspect ratio to 9:16, set speed to 2×, and click Export
2.Observe: the progress bar shows a percentage, but the tab is completely frozen — no scrolling, no UI interaction possible
Try clicking "Cancel" or navigating away — the tab does not respond until FFmpeg yields
On a mid-range laptop or phone, the browser may show "Page Unresponsive" and offer to kill the tab
If the tab is killed, all processing progress is lost with no recovery path — user must start over
Expected behavior
FFmpeg processing should run in a Web Worker (or via the multi-threaded @ffmpeg/ffmpeg build with SharedArrayBuffer), completely off the main thread. The UI should remain fully interactive during export. A real-time progress bar should receive messages from the worker via postMessage. A functional "Cancel" button should terminate the worker and clean up memory. If the browser tab is closed or refreshed mid-export, the user should receive a warning ("Export in progress — are you sure you want to leave?") via the beforeunload event.
Actual behavior
FFmpeg.wasm runs in single-threaded mode on the main browser thread. The entire tab freezes for the full duration of the export. The displayed progress bar likely reflects FFmpeg's internal log callbacks, but the UI itself cannot update, animate, or respond to user input while processing is active. There is no cancel mechanism — even if a cancel button exists, it cannot be triggered because the thread is blocked. On lower-end devices, the browser triggers an "Aw, Snap!" or "Page Unresponsive" crash dialog. For the app's stated 2GB file limit, this is not an edge case — it is the primary use case.