Repository navigation
fix(download): keep the download iframe alive after a successful export - #27
Merged
Merged
Conversation
iOS Safari finalises a download when its initiating frame is removed, even while bytes it has already accepted are still being flushed to disk, so large exports came out truncated at a chunk boundary although the page had reported success. The iframe now stays until the next download replaces it and is only removed on failure.
gmaclennan
added this pull request to stack #26
September 17, 2026 08:56
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Large exports from iOS Safari came back truncated at an IDAT chunk boundary with no IEND, at 42% and 56% in two runs, even though the page had reported Saved. The page-side sink only learns that the service worker's network consumer has read a chunk, not that it is on disk, and on iOS the download layer buffers well ahead of the disk. Removing the hidden iframe that initiated the download in the export's finally block then made iOS Safari finalise the download with whatever it had flushed.
The iframe now stays in the document after a successful export and is replaced when the next download starts; it is still removed on failure so an aborted export leaves nothing behind. Desktop WebKit, Chromium and Firefox never showed the problem because they finish writing before the page does, so the existing e2e suite covers the unchanged paths only; verification is a re-run of the 1200×1200 mm at 288 dpi export on the phone.
Stack created with GitHub Stacks CLI • Give Feedback 💬