Reviews for Save Page WE
Save Page WE by DW-dev
Review by Firefox user 12552652
Rated 5 out of 5
by Firefox user 12552652, 7 years agoFirefox's native save format is an html file next to a resource folder. These resource folders clutter the local directory, and make it difficult to move, copy, or delete these saves, because every operation needs a pair operation for the folder. Save Page WE (SPWE) solves all these issues by embedding the resource folder in the HTML file. Historically, two other addons do the same thing, UnMHT and Mozilla Archive Format (MAF). Both have special file formats, .mht and .maff respectively, which cannot be opened unless the addon is installed. Since these other addons are deprecated, their special file formats are no longer acceptable. Save Page WE's pure html file format is a clearly superior engineering solution which does not require addons. This review has shrunk in length significantly from its previous versions, thanks to a number of admirable technical improvements by SPWE.
The other two addons produce the save file dialog before constructing the save. Because of this, MAF has severe problems with silent corruption, and UnMHT must detect failure and alert to re-try. SPWE reverses the order, which solves this issue intrinsically.
UnMHT and SPWE have excellent accuracy in their saves, with small differences going either way. MAF falls behind. Native Firefox saving sometimes fails outright to produce a file.
SPWE saves usually have smaller filesize than UnMHT's. SPWE's saving speed is consistently 40% faster than UnMHT, independently of file size. Some pages take 20 seconds to save, so this helps.
SPWE re-downloads resources at the time of saving. (UnMHT does too.) In practice, this almost never causes any change, only with unusual server configurations and livestream thumbnails.
As a WebExtensions addon, SPWE cannot save Firefox Reader pages, because "Firefox and Chrome do not allow loading of content scripts into [about: pages]." A workaround is to save natively as html+folder, host the save with a local web server, and re-save with SPWE. For the local web server, the addon developer suggests the Google Chrome App called “Web Server for Chrome”. Another option is to install python, run "python -m SimpleHTTPServer 8080" in a console, and then navigate to http://localhost:8080/.
The quotations in this review come from the addon developer.
The following considerations exist, but have caused no problems:
"Save Page WE cannot re-save a “.mht” file because Firefox will not load a content script into a page saved by UnMHT." SPWE cannot re-save local html files with "_files" folders, because "Both Firefox and Chrome do not allow a page to access cross-origin local ‘file:’ resources." Both of these problems can be worked around using the local web server trick.
"The JSFiddle results section (lower right quadrant) is contained in a cross-domain sandboxed iframe. Save Page WE saves the contents of same-domain iframes, but does not save the contents of cross-domain iframes.
I have looked at how UnMHT handles this case and, as far as I can see, UnMHT creates a security risk when the saved page is re-opened. This is because the original cross-domain iframe is in effect loaded as a same-domain iframe when the saved page is re-opened." This applies to Disqus as well.
The other two addons produce the save file dialog before constructing the save. Because of this, MAF has severe problems with silent corruption, and UnMHT must detect failure and alert to re-try. SPWE reverses the order, which solves this issue intrinsically.
UnMHT and SPWE have excellent accuracy in their saves, with small differences going either way. MAF falls behind. Native Firefox saving sometimes fails outright to produce a file.
SPWE saves usually have smaller filesize than UnMHT's. SPWE's saving speed is consistently 40% faster than UnMHT, independently of file size. Some pages take 20 seconds to save, so this helps.
SPWE re-downloads resources at the time of saving. (UnMHT does too.) In practice, this almost never causes any change, only with unusual server configurations and livestream thumbnails.
As a WebExtensions addon, SPWE cannot save Firefox Reader pages, because "Firefox and Chrome do not allow loading of content scripts into [about: pages]." A workaround is to save natively as html+folder, host the save with a local web server, and re-save with SPWE. For the local web server, the addon developer suggests the Google Chrome App called “Web Server for Chrome”. Another option is to install python, run "python -m SimpleHTTPServer 8080" in a console, and then navigate to http://localhost:8080/.
The quotations in this review come from the addon developer.
The following considerations exist, but have caused no problems:
"Save Page WE cannot re-save a “.mht” file because Firefox will not load a content script into a page saved by UnMHT." SPWE cannot re-save local html files with "_files" folders, because "Both Firefox and Chrome do not allow a page to access cross-origin local ‘file:’ resources." Both of these problems can be worked around using the local web server trick.
"The JSFiddle results section (lower right quadrant) is contained in a cross-domain sandboxed iframe. Save Page WE saves the contents of same-domain iframes, but does not save the contents of cross-domain iframes.
I have looked at how UnMHT handles this case and, as far as I can see, UnMHT creates a security risk when the saved page is re-opened. This is because the original cross-domain iframe is in effect loaded as a same-domain iframe when the saved page is re-opened." This applies to Disqus as well.