Flux ArtDo not tie success to the picker closing
After a Flux Art image enters a custom editing tool, the user choosing a save location does not mean the file has been written. The browser may only have returned a file handle; creating a writable stream, writing the content and closing it to commit can still fail. This article covers the receiving application's own save workflow, not a claim that the platform can write directly to arbitrary local directories. Acceptance means the user-specified file actually contains this output and opens on the receiving side, not merely that a dialog closed or a green message appeared.
Prepare the candidate output before asking for a destination
Prepare a clearly identified output version before the user starts saving, display its type and suggested filename, and let the user actively choose the target. This avoids discovering after selection that the content is not ready and helps keep the operation tied to an explicit user action. Do not silently select paths or overwrite unknown files in the background. If an existing file must be replaced, clearly identify the target and content version and follow the system's confirmation flow. Retain original assets separately from candidate exports; never test saving by overwriting the only source file.
Separate the handle, stream and commit
A handle returned by showSaveFilePicker does not prove a write has occurred. createWritable creates a writable stream, and changes made through that stream are not reflected in the handle's corresponding file until the stream closes. The normal sequence waits for write, then for close to succeed. Do not announce the entire save as complete immediately after write returns. Support for the interface and support for the picker are also distinct checks: detect the complete path you will actually use. The table below defines what may be reported at each stage without extrapolating one browser's support to every device.
| Stage | Actual result | Correct reporting scope |
|---|---|---|
| User selects a target | Handle obtained, or selection canceled | Writing is not yet proven |
| Create a writable stream | Stream available, or request denied | Preparing to write |
| Write data | write succeeds or fails | Close and commit are still pending |
| Close the stream | Actual close result | Normal save-completion boundary |
| Verify the target file | Readable, with the correct version | This file passed delivery checks |
| Picker unsupported | Use an explicit alternative | Do not falsely claim in-place replacement |
Cancellation is a valid outcome, not a mandatory retry
When the user cancels selection, return to a state where editing can continue. Do not repeatedly reopen the dialog or clear the candidate output. Record permission denial, write failure and close failure at their actual stages, retaining assets the user can try saving again. If exception handling needs to abort a stream that has not closed, perform controlled cleanup appropriate to its state. Do not assume the abort itself succeeded, and never automatically convert failure into Saved. When an existing file is involved, verify its final state; if unknown, explain that it needs checking.
Specify whether existing content is retained
Whether existing data is kept when the writable stream is created affects the meaning of later writes. Do not mix default behavior with a workflow that needs partial modification. For a complete new image export, explicitly write the full candidate content rather than treating the old file as a byte container that can be spliced arbitrarily. Multiple tabs or concurrent writers can also compete to overwrite a file, so coordinate saves to the same target in your application. The final success message alone does not prove that earlier versions were properly preserved.
Test the close boundary with recoverable files
Suppose a tester saves image A to a dedicated test location, first observing acquisition of the handle and then the write and close results. This is hypothetical verification, not a real customer record. On the normal path, check that the file opens and its content matches A. Then simulate write and close failures using an isolated test double, confirming that the interface does not report success early. Also test cancellation, ensuring that neither the old file nor the candidate asset becomes a deletion target. Use recoverable copies; do not manufacture mid-save failures on the only copy of a real business file.
Explicitly switch delivery methods when unsupported
File-picker availability is limited. In unsupported environments, provide a verified alternative such as a normal download and explain that the result goes to the browser-managed download location or a location determined by its settings. A download path is not evidence that the original file handle was obtained, and it cannot promise replacement of a specified old file. Keep success evidence separate: direct writes require actual stream completion and target-content checks, while downloads use their own confirmable delivery outcomes. Do not hide capability differences behind a generic message.
Open the actual file for final acceptance
Check the target filename, format, dimensions, content version and readability at handoff. If the design allows readback verification, perform it only within legitimate authorization. Compare re-encoded output with the approved candidate version; it need not necessarily match the source file's bytes. Record the operating system, browser, actual save method and error stage. Keep untested power-loss recovery, concurrent overwrites and special-directory behavior marked unknown. A normal successful close does not justify a guarantee against data loss under every failure condition.
References and usage boundaries
Technical references checked on November 9, 2026: the file picker is documented at https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker and writable-stream creation and close-based commits at https://developer.mozilla.org/en-US/docs/Web/API/FileSystemFileHandle/createWritable . Flux Art outputs can be used commercially. Input asset rights and product authenticity need separate verification; the API entry point is https://flux-art.net/en/openapi . The save state machine and acceptance checklist here are recommendations for custom tools, not a grant of additional filesystem permissions to a web page.