v1.23.3

gildas-lormeau/SingleFilev1.23.3Sep 2, 2026by gildas-lormeau

AI Summary

This release focuses on resolving critical bugs affecting file uploads, memory management, and archive extraction. It improves stability by fixing viewport sizing, lazy-loading behavior, and self-extracting archive compatibility.

Key Highlights

  • Fixed corrupted multi-page archives during upload to WebDAV and cloud storage
  • Improved memory management by releasing saved page tabs when closed
  • Resolved viewport sizing issues that caused excessive headers in scripts
  • Enhanced self-extracting archive compatibility with various ZIP readers
  • Fixed lazy-loading pass to wait for stylesheets and ignore zero-height targets

Full Release Notes

### Fixes

Extension

- The page viewer displays the error when a saved page cannot be shown instead of leaving the tab blank
- A page saved to a destination such as WebDAV, GitHub, Google Drive, Dropbox, S3 or a REST API is uploaded byte for byte; a multi-page archive saved again from the editor was decoded as text first and arrived corrupted
- The page opened by "open the saved page" is released when its tab is closed instead of staying in memory for the whole session; reloading the tab still works
- The first page capture requested by another extension after its approval targets the page that was active when it asked, not the approval page
- Switching profiles in the editor keeps the options a regular save would use on browsers that cannot save in the background
- A BOM is no longer prepended to an archive requested through the extension API

Page capture (core 1.5.120)

- Pages that size their blocks from the viewport in a script were saved with enormous headers; the screen size is restored before the resize event that ends the lazy-loading pass (#1603)
- The lazy-loading pass stays open while the page inserts stylesheets, and zero-height observer targets are no longer reported as visible
- Page text can no longer close the SingleFile comment, a "-->" coming from an infobar template broke out of it

Self-extracting archives

- The charset declaration stays inside the 1024-byte scan window when the doctype is long
- The canonical link and the viewport meta are escaped in self-extracting pages
- The recovery payload of universal self-extracting pages is written and read little-endian whatever the host byte order, and an unassigned newline code is rejected when extracting
- The zip data comment is searched in the whole document when extracting
- The language encoding flag is set on the page.pdf records, and both prescan windows are measured from the start of the file under the PNG face
- The entries are compressed once; the passes that change the page layout copy them instead of compressing them again
- A self-extracting page whose extra data is relocated ends at the end of central directory record, so ZIP readers that reject trailing bytes open it