MAF (Mozilla Archive Format) and related matters.

[hilbert]

The attached files are of a web page (complete) saved as a single file [two versions thereof] from: http://www.wikihow.com/Force-Install-In ... in-Firefox. It was saved using Cyberfox 51.0.3 browser in MAF—Mozilla Archive Format—with the usual .MAFF extension enabled by the MAF add-on version 4.1. The file later opens normally as both a single .MAFF file and also when unzipped into its direcories and files, i.e.: when the index.html is opened. Specifically, in Cyberfox 51.0.3 and in both instances on reload the images within the page display normally.

In Pale Moon versions 27.1.2 both 32 and 64-bit versions and 27.0.3, 64* bit with the Pale Moon-specific MAF add-on.xpi file version 1.0.2 installed (which seems to be a fork of the original Mozilla one by a different author), the file saved from Cyberfox loads text perfectly but the images DO NOT load with all three version of PM.

When the same page is saved from within Pale Moon with its 1.0.2 MAF add-on installed then the images do actually load correctly!

Now, as this is a Pale Moon site, it is easy to blame Cyberfox and or its 4.1 version of the MAF add-on but that's not the point. Trouble is, where does the incompatibility actually lie? As Pale Moon will not install the normal Firefox 4.1 version, it is not possible to tell which add-on is at fault or where the specific incompatibility lies. There appears to be no readily available changelog in either MAF add-on that points to specific difference between them. Yes, I suppose I could go to the source and compare them but that would be a lot of bother as I'm not a writer of Mozilla add-ons, moreover, with different authors for each, it probably mean that I'd have to expend considerable effort. As it is the Pale Moon of the MAF add-on that's been modified to be compatible with changes made to Pale Moon, then it seems reasonable to begin the investigation here.

From my perspective, MAF is a very important format even if it receives little recognition, so compatibility is a very significant issue. The only real, practical alternative to saving web pages as a single web archive file is to use the MHTML/MIME HTML (.MHT) format that's supported by Internet Explorer** but often there are good technical reasons for avoiding it which I will not elaborate upon here [no, I not having a dig at Microsoft here].

I will bring this matter to the attention of the developer(s) as well as another issue that I have already raised with the developer of the Firefox version but which remains unresolved (note: the bug is present in both versions).

Second Issue: When I mentioned the bug to the developer several months ago it was with MAF add-on version 4.0.2 and Cyberfox but it has to be mentioned here because, whilst FF 4.02. 4.1 and PM 1.0.2versions all exhibit the bug, the extent of the problem varies considerably between them. Specifically, the conversion utility that's built into the MAF add-ons to convert from MAF to MHT and vice versa is essentially broken, definitely so in the MAF--> MHT conversion (I cannot comment on the conversion from MHT --> MAF as I've not done sufficient testing).

In essence, the problems are these:

1. When converting from MAF to MHT, some *working* MAF files either do not convert at all, or some of the converted files later fail to load (or display) in browsers. The browsers involved are recent versions of Internet Explorer [sans add-on, as MHT is native to IE], and Firefox (& forks) with a recent MAF add-on installed.

2. I recall the MAF conversion utility working properly without error in much older versions of Firefox (and forks) but I cannot be specific as to which ones. There were errors but only when the MAF source file was also faulty.

3. The problem became first apparent some months ago with Cyberfox 64-bit and MAF 4.0.2, but the fault may have been there in various earlier versions as I had not used the utility for some time previously. With Firefox and MAF 4.0.2, between 10 and 20% of working MAF files either do not convert or are faulty on reload.

4. With Cyberfox and MAF 4.1, a complete batch of 21 working MAF files failed to be converted (all generated errors). The identical result occurred with SeaMonkey version 2.46. This failure was earlier today, it precipitated this post!

5. With Pale Moon versions 27.0.3 and 27.1.2 and Pale Moon MAF 1.0.2—using the same 21 files as in #4—only two working MAF files failed to convert. At present, this combination is seemingly the only usable combination. Even so, every converted file must be tested: at best it's unreliable, at worst it's an unacceptably high failure rate.

6. The 21 files that all failed conversion were saved from the Internet Archive's 'Wayback Machine' pages. Except to say that all these saved MAF pages reloaded in Cyberfox/MAF 4.1 (i.e.: they were all OK from that perspective), I have not investigated whether there is anything specifically unusual with the Wayback Machine's pages in general (and remember pages from elsewhere also failed at other times albeit not as spectacularly—nevertheless, that has to be irrelevant as the saved 'Wayback' pages actually did reload OK.).

Note 1: The Web site as shown in the attachment files implies that incompatible extension were loaded in Cyberfox and or Pale Moon. This is certainly not the case (but I had actually intended to try old MAF .xpi files after encountering the errors. As stated earlier, I recall older combinations actually worked properly. FYI, Pale Moon only has one add-on installed which MAF v1.0.2.

Note 2: The environment is Windows 7, 64-bit, sp1, 8GB RAM.

Apologies for the tortuously long post,

_

* 32-bit not tried.

** .MHT files will also load in Firefox, Pale Moon etc. but only with the MAF add-on installed.

[Lootyhoof]

If you need a valid point of comparison, MozArchiver is essentially MAF version 3.1.3.

It's quite possible that MAF 4.0.0 and above introduced regressions compared to this older version though, as several features had to be cut back in order for the developer to make MAF (semi-)compatible with multiprocess in Firefox.

[miss config]

Installed the Mozilla MAF (MAFF) extension in Pale Moon Browser, with help of Moon Test. Can save to .maff file multiple tabs-web pages. No-way, no-how can I open the saved file in Pale Moon Browser: following message: Pale Mooon Browser has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. close program.
Can open and save to .maff file with Firefox - which I hang on to as an offline browser to open .maff files. Within limits I understand the difference-incompatibility issues with extensions (I am not a techie, I am a home user of Firefox since its beginnings, and the MAF Extension. I rely heavily on the .maff extension for saved research to read and work with at my own leisure. If this extension could be made workable, or re-written to work with Pale Moon Browser, I would be extremely grateful and appreciative.

[Lootyhoof]

Installed the Mozilla MAF (MAFF) extension in Pale Moon Browser, with help of Moon Test. Can save to .maff file multiple tabs-web pages. No-way, no-how can I open the saved file in Pale Moon Browser: following message: Pale Mooon Browser has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. close program.
Can open and save to .maff file with Firefox - which I hang on to as an offline browser to open .maff files. Within limits I understand the difference-incompatibility issues with extensions (I am not a techie, I am a home user of Firefox since its beginnings, and the MAF Extension. I rely heavily on the .maff extension for saved research to read and work with at my own leisure. If this extension could be made workable, or re-written to work with Pale Moon Browser, I would be extremely grateful and appreciative.

MozArchiver (mentioned in the post directly above yours...) exists for this very reason.

https://addons.palemoon.org/extensions/mozarchiver/

[hilbert]

If you need a valid point of comparison, MozArchiver is essentially MAF version 3.1.3.

It's quite possible that MAF 4.0.0 and above introduced regressions compared to this older version though, as several features had to be cut back in order for the developer to make MAF (semi-)compatible with multiprocess in Firefox.

Thanks for the info that MozArchiver is essentially MAF 3.1.3. On evidence of what's happened that makes some sense. One of the problems is that with so many versions of Firefox (and forks having to follow) and .xpi files also having to update that it is not easy to revert to both earlier executable/binaries and the identical .xpi file combinations that actually worked, so doing comparative tests of various combinations on old versions is difficult. In my case, as an end user, I don't have the requisite files any longer. I was in the habit of saving the .xpi files separately. In fact, without digging deeper into the archives, I find I have 15 versions of .xpi MAF releases from 0.4.2 (2004-10-14 - modify date) to 2.0.1.0-fx dev site version 2011-09-10) but unfortunately I obviously stopped saving them after that so I can't test ver 3.1.3.

When I made my original post I was in the thick of another project so the amount of time I could devote to the problem was limited but the bug was not unsurprised (as it had happened previously—that's when I contacted the developer). When I get a moment, I'll try and set up another test jig but I'm not sure it will be all that helpful if I can't get the 3.13 xpi.

Irrespective, the solution for present is to use MozArchiver/PM.

Incidentally, the reason why MAF needs to be converted in bulk to MHTML format is that there are no native MAF viewers for file managers, Explorer, Directory Opus etc., which is a real nuisance. Thus, to review say many hundreds of MAF files quickly it's easier to convert them to .MHT files which views in most viewers (it's then a simple matter of moving down the file list with the web page in view in the viewer pane. If the MHTML matter cannot be fully resolved then perhaps the plugin could be adapted to just bulk unzip the MAFs into a directory but bring out the index.html files from their sudirectories up one level and sequentially renumber them to stop write-overs. When finished viewing/sorting etc. then the unzipped versions can simply be deleted (and keeping the MAF as the archive). In some ways—although considerably messier—it avoids all the usual problems associated with re-coding to MHT.

Thanks again.

[Lunarpallor]

One of the problems is that with so many versions of Firefox (and forks having to follow) and .xpi files also having to update that it is not easy to revert to both earlier executable/binaries and the identical .xpi file combinations that actually worked, so doing comparative tests of various combinations on old versions is difficult. In my case, as an end user, I don't have the requisite files any longer. I was in the habit of saving the .xpi files separately. In fact, without digging deeper into the archives, I find I have 15 versions of .xpi MAF releases from 0.4.2 (2004-10-14 - modify date) to 2.0.1.0-fx dev site version 2011-09-10) but unfortunately I obviously stopped saving them after that so I can't test ver 3.1.3.

When I made my original post I was in the thick of another project so the amount of time I could devote to the problem was limited but the bug was not unsurprised (as it had happened previously—that's when I contacted the developer). When I get a moment, I'll try and set up another test jig but I'm not sure it will be all that helpful if I can't get the 3.13 xpi.

The Mozilla add-ons website hosts all previous versions of extensions. You can find these for MAF along with the changelogs here.
The MAFF specification can be found here.

I would assume that the cause of this incompatibility from the fork of MAF are changes to the format in newer versions of MAF. It is probably backwards compatible so that Pale Moon MAFFs open fine in Firefox, but the reverse is broken. Any changes would have to be backported to MozArchiver, and I've no idea who maintains it or if it's even being maintained.

[coffeebreak]

Any changes would have to be backported to MozArchiver, and I've no idea who maintains it or if it's even being maintained.

It was forked and is actively maintained by Lootyhoof who has posted in this thread, most recently two posts above yours (where you'll find a link to Mozarchiver's page on the Pale Moon add-ons site).

That page also provides this information.

[Lunarpallor]

Off-topic:

Any changes would have to be backported to MozArchiver, and I've no idea who maintains it or if it's even being maintained.

It was forked and is actively maintained by Lootyhoof who has posted in this thread, most recently two posts above yours (where you'll find a link to Mozarchiver's page on the Pale Moon add-ons site).

That page also provides this information.

I noticed but the rules (whether they have been modified from phpBB defaults or not) say not to double post and I saw no way of editing my post when I later found the time to look into it. I decided against it, especially since there's no way to post without bumping on forums like these.

Anyhow, I did notice that the MAFF specification page as of March 2017 has not changed from March 2016, the time of the update that MozArchiver is forked from, as can be seen by comparing these archives:

https://web.archive.org/web/20160304025 ... ation.html
https://web.archive.org/web/20170306234 ... ation.html

I would assume that the problem comes either after the last release of MozArchiver, Sept. 2016 according to github, which leaves only MAF 4.0.2 or 4.1.0... only there is no mention on github of anything other than bugfixes. So actually where to start looking depends on what Lootyhoof did with the initial commit in Feb. 2016. Whether 3.1.3 or higher.

It's also possible that the MAF website is not actually up-to-date, as it explicitly says:

This document is a working draft aimed at providing a detailed specification for the MAFF file format, with the goal of ensuring the interoperability between different implementations.

In this stage of development, this document describes the essential aspects of the file format and is updated to reflect actual technical questions or foreseen implementation issues. Implementations based solely on this document are not recommended; developers are instead encouraged to discuss their implementations on the mailing list of the MAF project.

The Mozilla Archive Format extension for Firefox currently implements the MAFF specification at the basic conformance level. Eventually, the MAF extension will be updated to the normal conformance level, when the related aspects of the specification are stabilized.

And I've seen many website sections just die without receiving updates for long periods of time even though things are still being worked on in the background.

[coffeebreak]

Off-topic:

I noticed but the rules .... say not to double post and I saw no way of editing my post when I later found the time to look into it. I decided against it, especially since there's no way to post without bumping on forums like these.

Probably the rule concerning double posts isn't meant to prevent a second post that supplements the content of your first post. :)

Concerning the first half of your sentence that I quoted earlier:

Any changes would have to be backported to MozArchiver...

Please note this post:

It's quite possible that MAF 4.0.0 and above introduced regressions compared to this older version though, as several features had to be cut back in order for the developer to make MAF (semi-)compatible with multiprocess in Firefox.

(And also note MAF's changelog on AMO for v4.0.0 and up.)

I am not a developer, so please take that grain of salt with my opinion here, but...
Pale Moon has not adopted multi-process, and the notion of backporting changes (and loss of features) whose purpose is to support multi-process sounds like a dubious undertaking.