Also, when saving to NTFS partition under Linux, same file-name restrictions as in Windows apply - no special characters ":/\?*<>|" in file names, while : (colon) is very common in titles... (I'm not sure if offering wrong Filename from <title> for Ctrl+S is problem of MozArchiver or Palemoon itself? Saving mht to bad filename just silently fails...)
Also while saving files on Linux, I'd like to copy it to FAT32 flash-disk and transfer to Windows without problems with file-names...
Can there be an option (about:config) for safeFileNames ?
-----
I also formerly patched my version of MozArchiver to log into Browser Console, that it succesfully saved the file:
in extensions\mozarchiver@lootyhoof-pm.xpi\chrome\content\engine\MhtmlArchivePage.js
at end of file in _writeArchive :
Code: Select all
try{
let { console } = Cu.import("resource://gre/modules/Console.jsm", {});
let fi = this.archive.file;
console.log('Saved '+(fi.leafName||fi.name));
}catch(x){}
(Because saving often writes in Downloads popup on green arrow-down button, that it "failed", but continues saving and saves it well, maybe depending on pages containing non-existent frames or I do not know why, and also when I close the tab too soon (as saving a page may take very long - especially if I aborted loading the page images with Escape, but saving is fetching them all, and I usually save it just before closing it...), but I'm now used to check browser console to see, that I may close the tab, that the file is already saved...)
-----
Does it really have to save all images, even if their parent element is hidden by css class and display:none and there is no javascript in MHT to ever display it ?
(Having them instead sanitized with urn:not-loaded: would make no difference on displayed output and would not crash saving on 32-bit system...)
Consider this poisonous article - there are 1286 images in section "all other articles by this author", that is hidden by toggle...
(Beware that it polutes the cache by that many useless images! If you right-click to download it without displaying in PM and inspect it in text editor, there is multitude of <dd class="typeCont"> , their parent is hidden by class=collapse ( id="clankyAutora" ) leading to display:none in css file... but simply asking img.offsetWidth getting null could trigger inspecting, whether the parents have display:none and in that case avoid saving the image and instead sanitize it with urn:not-loaded: ...? )
(In my 32-bit version saving that to MHTML, it soon has status "failed" in downloads, so that it cannot be aborted, but it keeps fetching 1000 images (visible in Browser Console) until it fails with "out of memory" error...)
(I repeatedly tried to convince the author that it is reckless to have over 1000 vain images on each page... But there are other similar cases, even page with over 3000 images can be seen...)
πα½
