From mozilla at fr-net.de  Sun Nov  1 04:45:22 2009
From: mozilla at fr-net.de (Frank)
Date: Sun, 1 Nov 2009 13:45:22 +0100
Subject: [Maf] Possible BUG in v0.15.1 and newer versions
Message-ID: <hcjvr0$dvh$1@mozdev.mozdev.org>

Hey,

first of all great work, but now to my problem, occurring on Windows

A few days ago I have installed maf v0.14.3 and saved a page (e.g. 
google.de) as mhtm and the images and everything else was embedded in the 
file.

Then I have updated to v0.15.1 and v.0.16.0 save the same page as mhtm but 
in the file there was only then html-document, no images, no javascript 
files.


I'm able to reproduce this behaviour everytime when swiching the versions. 
The version of Mozilla (3.0.xx or. 3.5.4) doesn't have any effect, but what 
is really strange that this behaviour doesn't appear on Linux.

Greets Frank


Content of the mhtm saved with 0.14.3
From: <Saved by Mozilla 5.0 (Windows; de)>
Subject: Google
Date: Sun Nov 01 2009 13:33:47 GMT+0100
MIME-Version: 1.0
Content-Location: http://www.google.de/
Content-Type: multipart/related;
 boundary="----=_NextPart_000_0000_57315E2D.D24B5ADB";
 type="text/html"
X-MAF-Version: Produced By MAF V0.14.3

This is a multi-part message in MIME format.

------=_NextPart_000_0000_57315E2D.D24B5ADB
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.google.de/
...


Content of the mhtm saved with 0.15.1
From: <Saved by Mozilla 5.0 (Windows; de)>
Subject: Google
Date: Sun Nov 01 2009 13:06:21 GMT+0100
MIME-Version: 1.0
X-MAF: Produced By MAF V0.15.1
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.google.de/
... 



From paolo.01.prg at amadzone.org  Sun Nov  1 08:06:46 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 01 Nov 2009 17:06:46 +0100
Subject: [Maf] Possible BUG in v0.15.1 and newer versions
In-Reply-To: <hcjvr0$dvh$1@mozdev.mozdev.org>
References: <hcjvr0$dvh$1@mozdev.mozdev.org>
Message-ID: <4AEDB216.2080804@amadzone.org>

Hello Frank,

thanks for your report! Unfortunately, I wasn't able to reproduce
the problem on my machine. This is the configuration I used:
 * Windows XP Professional
 * Firefox 3.0.15
 * Mozilla Archive Format 0.15.1
 * Enabled: Use the integrated "Save Complete" extension
 * Enabled: Create MHTML files fully compatible with other browsers

I saved <http://www.google.de/> as MHTML and opened the archive after
clearing the cache, and the main image displays correctly. However,
there is a difference if I repeat the test with the latest development
version of Mozilla Archive Format: a JavaScript file that was ignored
by MAF 0.15.1 is now included.

Maybe this change may solve the problem you are experiencing with the
images too. After fixing some other bugs in this area, I packaged the
new version as MAF 0.16.2. This experimental version will be available
from the site in a few hours, meanwhile you can download it from here:

http://downloads.mozdev.org/maf/maf-0.16.2.0-fx.xpi

Please let me know if this solves your problem, after following the
steps above. If not, we may go on with the troubleshooting in other
ways.

Regards,
Paolo

Frank wrote:
> Hey,
> 
> first of all great work, but now to my problem, occurring on Windows
> 
> A few days ago I have installed maf v0.14.3 and saved a page (e.g. 
> google.de) as mhtm and the images and everything else was embedded in the 
> file.
> 
> Then I have updated to v0.15.1 and v.0.16.0 save the same page as mhtm but 
> in the file there was only then html-document, no images, no javascript 
> files.
> 
> 
> I'm able to reproduce this behaviour everytime when swiching the versions. 
> The version of Mozilla (3.0.xx or. 3.5.4) doesn't have any effect, but what 
> is really strange that this behaviour doesn't appear on Linux.
> 
> Greets Frank
> 
> 
> Content of the mhtm saved with 0.14.3
> From: <Saved by Mozilla 5.0 (Windows; de)>
> Subject: Google
> Date: Sun Nov 01 2009 13:33:47 GMT+0100
> MIME-Version: 1.0
> Content-Location: http://www.google.de/
> Content-Type: multipart/related;
>  boundary="----=_NextPart_000_0000_57315E2D.D24B5ADB";
>  type="text/html"
> X-MAF-Version: Produced By MAF V0.14.3
> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_0000_57315E2D.D24B5ADB
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
> Content-Location: http://www.google.de/
> ...
> 
> 
> Content of the mhtm saved with 0.15.1
> From: <Saved by Mozilla 5.0 (Windows; de)>
> Subject: Google
> Date: Sun Nov 01 2009 13:06:21 GMT+0100
> MIME-Version: 1.0
> X-MAF: Produced By MAF V0.15.1
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
> Content-Location: http://www.google.de/
> ... 



From paolo.01.prg at amadzone.org  Sun Nov  1 12:08:30 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 01 Nov 2009 21:08:30 +0100
Subject: [Maf] [ANN] MAF 0.16.2 (experimental) released
Message-ID: <4AEDEABE.5010504@amadzone.org>

Hello,

Mozilla Archive Format experimental version 0.16.2 is now officially
available for download at <http://maf.mozdev.org/>.

Starting from this version, the File Title and Title Save extensions
are not required anymore to use the page title instead of the file
name in the "Save As" dialog box. This functionality can still be
achieved with one of the cited extensions, but can also be enabled
independently from the MAF preferences.

In order for the new MAF preference to work as expected, it is
recommended to uninstall the File Title or Title Save extension first.
Even though these extensions are still compatible with Mozilla Archive
Format when the new preference is not enabled, they are not always
available for recent versions of Firefox, and are unmaintained to date.

Changes from 0.16.0 to 0.16.2:

    * New: Preference to use the page title instead of the default
       suggested file name in the "Save As" dialog.
    * New: The order of the tabs is now preserved when opening and
       saving multi-page MAFF archives.
    * Change: Now the character set specified in MAFF archives is always
       enforced, and a different character set cannot be selected.
    * Change: Now the Save Complete component is faster when saving
       pages containing many images or other content.
    * Change: Now the Save Complete component does not save the main
       document twice, even if it is referenced by the saved files.
    * Change: Now the Saved Pages Conversion Wizard doesn't execute
       JavaScript or plugins before converting saved pages, since that
       may slow down or temporarily block the conversion process.
    * Change: Minor usability fixes in the Saved Pages Conversion
       Wizard.
    * Fix: The integrated Save Complete component now correctly reports
       errors that occur while downloading the main file.
    * Fix: The integrated Save Complete component sometimes failed to
       handle references to saved images or other content.
    * Fix: The Saved Pages Conversion Wizard might display unexpected
       behavior if the Enter key was pressed while converting.

Regards,
Paolo Amadini


From mozilla at fr-net.de  Sun Nov  1 15:21:29 2009
From: mozilla at fr-net.de (Frank)
Date: Mon, 02 Nov 2009 00:21:29 +0100
Subject: [Maf] Possible BUG in v0.15.1 and newer versions
In-Reply-To: <mailman.356.1257091846.85486.maf@mozdev.org>
References: <hcjvr0$dvh$1@mozdev.mozdev.org>
	<mailman.356.1257091846.85486.maf@mozdev.org>
Message-ID: <hcl53n$1p8b$1@mozdev.mozdev.org>

Hello Paolo

i have tried v0.16.2 with the same result, the google image is missing.
After i have cleared the cache and opened the mhtml the image was there,
once again i cleared the cache switch mozilla to offline mode and the
image was missing.

I have attached three files for you
google_0143.htm.mht   saved with v0.14.3
google_0162.mht       saved with v0.16.2
 -> both saved with the same settings, but they have different sizes

google_unhtm.mht      saved with unHTM  (as a reference)

in the next days I will continue testing with a cleaned up
mozilla-profile and maybe with a fresh mozilla installation.

Thanks for your support



Paolo Amadini schrieb:
> Hello Frank,
> 
> thanks for your report! Unfortunately, I wasn't able to reproduce
> the problem on my machine. This is the configuration I used:
>  * Windows XP Professional
>  * Firefox 3.0.15
>  * Mozilla Archive Format 0.15.1
>  * Enabled: Use the integrated "Save Complete" extension
>  * Enabled: Create MHTML files fully compatible with other browsers
> 
> I saved <http://www.google.de/> as MHTML and opened the archive after
> clearing the cache, and the main image displays correctly. However,
> there is a difference if I repeat the test with the latest development
> version of Mozilla Archive Format: a JavaScript file that was ignored
> by MAF 0.15.1 is now included.
> 
> Maybe this change may solve the problem you are experiencing with the
> images too. After fixing some other bugs in this area, I packaged the
> new version as MAF 0.16.2. This experimental version will be available
> from the site in a few hours, meanwhile you can download it from here:
> 
> http://downloads.mozdev.org/maf/maf-0.16.2.0-fx.xpi
> 
> Please let me know if this solves your problem, after following the
> steps above. If not, we may go on with the troubleshooting in other
> ways.
> 
> Regards,
> Paolo
-------------- next part --------------
An embedded message was scrubbed...
From: <Saved by Mozilla 5.0 (Windows; de)>
Subject: Google
Date: Sun Nov 01 2009 23:56:25 GMT+0100
Size: 13711
URL: <http://www.mozdev.org/pipermail/maf/attachments/20091102/650c7558/attachment-0003.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: <Saved by Mozilla 5.0 (Windows; de)>
Subject: Google
Date: Mon Nov 02 2009 00:03:57 GMT+0100
Size: 35165
URL: <http://www.mozdev.org/pipermail/maf/attachments/20091102/650c7558/attachment-0004.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: <Saved by UnMHT>
Subject: =?iso-2022-jp?B?R29vZ2xl?=
Date: Sun, Nov 01 2009 23:59:40 GMT+0100
Size: 23575
URL: <http://www.mozdev.org/pipermail/maf/attachments/20091102/650c7558/attachment-0005.mht>

From paolo.01.prg at amadzone.org  Mon Nov  2 07:27:41 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Mon, 02 Nov 2009 16:27:41 +0100
Subject: [Maf] Possible BUG in v0.15.1 and newer versions
In-Reply-To: <hcl53n$1p8b$1@mozdev.mozdev.org>
References: <hcjvr0$dvh$1@mozdev.mozdev.org>	<mailman.356.1257091846.85486.maf@mozdev.org>
	<hcl53n$1p8b$1@mozdev.mozdev.org>
Message-ID: <4AEEFA6D.6080303@amadzone.org>

Frank wrote:
> I have attached three files for you
> google_0143.htm.mht   saved with v0.14.3
> google_0162.mht       saved with v0.16.2
>  -> both saved with the same settings, but they have different sizes

Thank you for attaching the files, I think I have found the bug. The
problem was introduced in version 0.15.0 by the modification to use
localized suffixes for the data folders associated with complete web
pages, and occurs only for languages where the suffix is different from
"_files". In this situation, MAF always creates malformed MHTML files.

Version 0.16.3 should fix this issue:

http://downloads.mozdev.org/maf/maf-0.16.3.0-fx.xpi

Let me know if this version saves the page correctly.

Regards,
Paolo

From mozilla at fr-net.de  Mon Nov  2 11:21:03 2009
From: mozilla at fr-net.de (Frank)
Date: Mon, 02 Nov 2009 20:21:03 +0100
Subject: [Maf] Possible BUG in v0.15.1 and newer versions
In-Reply-To: <mailman.363.1257175707.85486.maf@mozdev.org>
References: <hcjvr0$dvh$1@mozdev.mozdev.org>	<mailman.356.1257091846.85486.maf@mozdev.org>	<hcl53n$1p8b$1@mozdev.mozdev.org>
	<mailman.363.1257175707.85486.maf@mozdev.org>
Message-ID: <hcnbcs$1l5e$1@mozdev.mozdev.org>

Hello Paolo

good news, you have fixed the bug.

Thanks for your support, and your excellent work.


Regards,
Frank



Paolo Amadini wrote:
> Frank wrote:
>> I have attached three files for you
>> google_0143.htm.mht   saved with v0.14.3
>> google_0162.mht       saved with v0.16.2
>>  -> both saved with the same settings, but they have different sizes
> 
> Thank you for attaching the files, I think I have found the bug. The
> problem was introduced in version 0.15.0 by the modification to use
> localized suffixes for the data folders associated with complete web
> pages, and occurs only for languages where the suffix is different from
> "_files". In this situation, MAF always creates malformed MHTML files.
> 
> Version 0.16.3 should fix this issue:
> 
> http://downloads.mozdev.org/maf/maf-0.16.3.0-fx.xpi
> 
> Let me know if this version saves the page correctly.
> 
> Regards,
> Paolo

From paolo.01.prg at amadzone.org  Mon Nov  2 14:02:02 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Mon, 02 Nov 2009 23:02:02 +0100
Subject: [Maf] [ANN] MAF 0.16.3 (experimental) released
Message-ID: <4AEF56DA.4000101@amadzone.org>

Hello,

Mozilla Archive Format experimental version 0.16.3 is now officially
available for download at <http://maf.mozdev.org/>.

Changes from 0.16.2 to 0.16.3

    * Change: Now the Save Complete component stores the comment with
       the original location only in the main document of the saved
       page.
    * Fix: MHTML files couldn't be created properly when the browser
       operated in some languages other than English.
    * Fix: The preference to use the page title instead of the default
       suggested file name didn't work for XHTML documents.

Regards,
Paolo Amadini


From paolo.01.prg at amadzone.org  Sun Nov  8 10:03:35 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 08 Nov 2009 19:03:35 +0100
Subject: [Maf] [ANN] MAFF specification: first draft now available
Message-ID: <4AF707F7.4090006@amadzone.org>

Hello,

the first draft of the technical specification for the MAFF file format
is now available at the official site of the MAF project on mozdev.org.

MAFF files are standard ZIP files containing one or more web pages,
images, or other downloadable content, with optional metadata. This open
format was first adopted as a real-world solution to save web pages
by the Mozilla Archive Format extension for the Firefox web browser,
providing an efficient alternative to the MHTML format.

Today, the availability of a technical specification for the MAFF format
is a great opportunity for extending MAFF support to other browsers and
applications as well. The specification will help the interested
developers by explaining the details of the file format, and most
importantly it will serve as a point of reference allowing all the
different implementations to be compatible with each other.

The specification itself only describes the file format and does not
depend on a particular programming language or Mozilla technology.
For developers interested in enhancing the support for MAFF in Firefox,
new developer documentation for the MAF extension is also available.

At this point, the specification is far from complete, and some basic
information is still to be added. Interested people and implementors
are encouraged to send early feedback to this mailing list. The working
draft will be periodically updated to reflect the received comments.

More information can be found here:

* Overview of the MAFF file format
   <http://maf.mozdev.org/maff-file-format.html>

* Technical specification of the MAFF file format
   <http://maf.mozdev.org/maff-specification.html>

* New developer documentation for the MAF extension
   <http://maf.mozdev.org/dev-documentation.html>

Regards,
Paolo Amadini


From bayun at progressors.org  Sun Nov  8 10:51:05 2009
From: bayun at progressors.org (=?UTF-8?B?0JrQvtGCINCR0LDRjtC9?=)
Date: Sun, 08 Nov 2009 20:51:05 +0200
Subject: [Maf] [ANN] MAFF specification: first draft now available
In-Reply-To: <4AF707F7.4090006@amadzone.org>
References: <4AF707F7.4090006@amadzone.org>
Message-ID: <4AF71319.7030709@progressors.org>

Hello, Paolo.

I have red specification draft, and I think that I have a useful 
addition to Extended conformance
level: list of additional meta-information locations, so applications 
(that generally can add multiple
additional files, and each apllication can have different set of these 
files) can distinguish meta-information
from saved content. I see many different uses for this feature (for 
example, to decide, what to
index in archive), but most obvious - removing this extra meta-info, 
transforming archive into Normal type.

And two more questions.

1) Are you really sure that specifications must support TWO date 
formats, and none of them
must be marked of "deprecated"? As for me, it's complicates any 
non-Mozilla reader implementation,
and gives nothing - at lest, 'Date' tag is not critical to correctly 
display saved page.

2) If you think that mime-types must be saved only "by ensuring that the 
file names of supported content
match a list of well-known file extensions", then what mapping must be 
used? This mapping must be
available for developers along with specification.
Personally, I think that it's wrong solution. There are mime-types that 
do not have extension at all (json, for example),
and it's easy to save mime-type, freeing reader from need to maintain 
list of extension/mime type mappings.

Also, I don't see point in claiming that 'pages saved inside MAFF 
archives should be treated as an atomic unit'.
In your example, user-agent (and it's user) better knows how it must 
update archive.

WBR,
Bayun.


Paolo Amadini wrote:
> Hello,
>
> the first draft of the technical specification for the MAFF file format
> is now available at the official site of the MAF project on mozdev.org.
>
>
> Regards,
> Paolo Amadini
>
> _______________________________________________
> Maf mailing list
> Maf at mozdev.org
> https://www.mozdev.org/mailman/listinfo/maf
>
>   


From paolo.01.prg at amadzone.org  Sun Nov  8 11:38:34 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 08 Nov 2009 20:38:34 +0100
Subject: [Maf] [ANN] MAFF specification: first draft now available
In-Reply-To: <4AF71319.7030709@progressors.org>
References: <4AF707F7.4090006@amadzone.org> <4AF71319.7030709@progressors.org>
Message-ID: <4AF71E3A.7040904@amadzone.org>

Hello Bayun,

thank you very much for your contributions, they are very helpful.

Comments inline:

> list of additional meta-information locations, so applications
> (that generally can add multiple
> additional files, and each apllication can have different set of these
> files) can distinguish meta-information
> from saved content. I see many different uses for this feature (for
> example, to decide, what to
> index in archive), but most obvious - removing this extra meta-info,
> transforming archive into Normal type.

Reserving some file names and locations for additional metadata is a
good idea, I will add a proposal for a naming scheme to the next
revision. Maybe reserved names might begin with a character like
"^", followed by any character other than "^", for example
"^headers.rdf". For vendor-specific additions, not in the
specification, file names may be required to start with
something like "^x-", for example "^x-headers.rdf".

> 1) Are you really sure that specifications must support TWO date
> formats, and none of them
> must be marked of "deprecated"? As for me, it's complicates any
> non-Mozilla reader implementation,
> and gives nothing - at lest, 'Date' tag is not critical to correctly
> display saved page.

Actually, the JavaScript date format is "deprecated" as you say, in
the sense that it should not be used when generating MAFF archives.
However, if an implementation is able to read the date at all, it
must support the JavaScript date format, to ensure compatibility
with MAFF version 1.

If we were inventing a new file format from scratch, I'd agree with
you that we should stick to standards as much as possible, but we're
building upon an existing format, and even in the future the files
created with the present implementation shouldn't be discriminated.

Besides, supporting the JavaScript format is really easy: if the date
string starts with three letters, a space and then three letters again,
just apply a transformation before feeding it to a RFC 5322 parser.

> 2) If you think that mime-types must be saved only "by ensuring that the
> file names of supported content
> match a list of well-known file extensions", then what mapping must be
> used? This mapping must be
> available for developers along with specification.

Yes, it will be part of the specification.

> Personally, I think that it's wrong solution. There are mime-types that
> do not have extension at all (json, for example),
> and it's easy to save mime-type, freeing reader from need to maintain
> list of extension/mime type mappings.

Of course most MIME types will not be part of the specification, but
they will be rare enough in actual web content that guessing them
incorrectly would not hinder rendering in practice. Moreover, browsers
already guess MIME types correctly based on the file extension in most
cases. In rare cases, however, the explicit MIME type declarations you
mention could be useful; I'm considering it as an advanced feature for
the "normal" level of the specification, in addition to the mandatory
file extension mappings.

> Also, I don't see point in claiming that 'pages saved inside MAFF
> archives should be treated as an atomic unit'.
> In your example, user-agent (and it's user) better knows how it must
> update archive.

This is true, to an extent. It may depend on the use case, but in
general I think that atomicity isn't a secondary point for authors
of MAFF packages. For example, each page might be digitally signed
as a whole, and updating single files would break things.

In any case, atomicity may be the default; additional metadata might
instruct enabled software about how the individual resources can be
updated.

Best regards,
Paolo


From maliz at gmx.ch  Tue Nov 10 00:48:28 2009
From: maliz at gmx.ch (maliz at gmx.ch)
Date: Tue, 10 Nov 2009 09:48:28 +0100
Subject: [Maf] Request: Support SeaMonkey 2.0
Message-ID: <4AF928DC.9030703@gmx.ch>

Hello

I'd like to thank Paolo Amadini for further developing MAF which was 
created by Christopher Ottley in the first place. And Christopher for 
his initial effort.

I'm a long time user of MAF on SeaMonkey, and Mozilla even longer ago.

Ottley's MAF 0.6.3 was installable on Mozilla and Firefox as well.
Since that time, I used a heavily stripped down version of MAF on 
SeaMonkey which was reliable, fast and easily adaptable to the different 
versions of SM (1.0, 1.1).
Now SM development has reached version 2.0. For this version adaption of 
the old MAF isn't easy anymore.

While the extension mechanism of SM has become more similar to the one
of FF it still is not possible to use Amadini's MAF 0.16.3 with SM.

For some time now I've been using FF, just do be able to save web pages 
with MAF - but what SeaMonkey user can really accept Firefox in the long 
term? ;) Or even get accustomed to it only.
Using SM for mail and FF for browsing side by side is a mess.

So I kindly request: Would you please adopt MAF to SeaMonkey 2.0.

Are there other SeaMonkey users with this need?

ciao
Ueli

From paolo.01.prg at amadzone.org  Tue Nov 10 05:57:32 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Tue, 10 Nov 2009 14:57:32 +0100
Subject: [Maf] Request: Support SeaMonkey 2.0
In-Reply-To: <4AF928DC.9030703@gmx.ch>
References: <4AF928DC.9030703@gmx.ch>
Message-ID: <4AF9714C.8090808@amadzone.org>

Hello!

Adding support for SeaMonkey 2.0 is actually something I'm considering
for one of the next versions of MAF. From the development point of view,
this should be quite easy, if no show-stoppers are present, now that
SeaMonkey is aligned with some of the programming interfaces of Firefox.
The most time-consuming activity instead will be to set up an initial
test environment first, and then actually test the most sensible parts
of the browser integration on the two products.

Maintaining the two products will require some more work for each
release, and I don't think I'll be able to keep up with all the
testing in detail. However, knowing that actual SeaMonkey users
are downloading from mozdev.org (where I release new versions
before publishing them on addons.mozilla.org) is indeed helpful;
thanks for letting me know! In this way, subtle bugs that I may
not see during the tests on Firefox may be caught by advanced
users like you before the version is made available to the
greater public. I appreciate your help in this regard.

As for an initial assessment of the feasibility and difficulty of the
development, Philip Chee is actually running a "porting" service on
MozillaZine, where developers and user may ask for help in making
extensions compatible. Since I could use some help in this regard too,
I'll ask there (<http://forums.mozillazine.org/viewtopic.php?t=500361>)
as this may speed up the process a bit.

Regards,
Paolo

maliz at gmx.ch wrote:
> Hello
> 
> I'd like to thank Paolo Amadini for further developing MAF which was
> created by Christopher Ottley in the first place. And Christopher for
> his initial effort.
> 
> I'm a long time user of MAF on SeaMonkey, and Mozilla even longer ago.
> 
> Ottley's MAF 0.6.3 was installable on Mozilla and Firefox as well.
> Since that time, I used a heavily stripped down version of MAF on
> SeaMonkey which was reliable, fast and easily adaptable to the different
> versions of SM (1.0, 1.1).
> Now SM development has reached version 2.0. For this version adaption of
> the old MAF isn't easy anymore.
> 
> While the extension mechanism of SM has become more similar to the one
> of FF it still is not possible to use Amadini's MAF 0.16.3 with SM.
> 
> For some time now I've been using FF, just do be able to save web pages
> with MAF - but what SeaMonkey user can really accept Firefox in the long
> term? ;) Or even get accustomed to it only.
> Using SM for mail and FF for browsing side by side is a mess.
> 
> So I kindly request: Would you please adopt MAF to SeaMonkey 2.0.
> 
> Are there other SeaMonkey users with this need?

From paolo.01.prg at amadzone.org  Tue Nov 10 13:09:54 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Tue, 10 Nov 2009 22:09:54 +0100
Subject: [Maf] [ANN] MAF 0.16.4 released
Message-ID: <4AF9D6A2.9060205@amadzone.org>

Hello,

Mozilla Archive Format version 0.16.4 is now officially available
for download at <http://maf.mozdev.org/>.

Changes from 0.16.3 to 0.16.4:

    * Change: Now the MAF items in the File menu are displayed by
       default.
    * Change: Standard file icons are now shown in the multiple tab
       selection dialog.

Regards,
Paolo Amadini


From paolo.01.prg at amadzone.org  Tue Nov 10 13:14:59 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Tue, 10 Nov 2009 22:14:59 +0100
Subject: [Maf] Request: Support SeaMonkey 2.0
In-Reply-To: <4AF9714C.8090808@amadzone.org>
References: <4AF928DC.9030703@gmx.ch> <4AF9714C.8090808@amadzone.org>
Message-ID: <4AF9D7D3.7060906@amadzone.org>

Paolo Amadini wrote:
> As for an initial assessment of the feasibility and difficulty of the
> development, [...]
> I'll ask there (<http://forums.mozillazine.org/viewtopic.php?t=500361>)
> as this may speed up the process a bit.

Unfortunately, the news here are not so good: SeaMonkey 2.0 does not
support some of the interfaces that MAF uses internally.

Porting MAF to SeaMonkey will not be as easy as I hoped.

Regards,
Paolo

From maliz at gmx.ch  Tue Nov 10 14:58:57 2009
From: maliz at gmx.ch (Ueli)
Date: Tue, 10 Nov 2009 23:58:57 +0100
Subject: [Maf] Request: Support SeaMonkey 2.0
In-Reply-To: <4AF9714C.8090808@amadzone.org>
References: <4AF928DC.9030703@gmx.ch> <4AF9714C.8090808@amadzone.org>
Message-ID: <4AF9F031.9030504@gmx.ch>

Ciao Paolo

Well, so after the good news follows some bad. :)
I followed your discussion with Philip Chee on the Porting thread on the 
MozillaZine forums 
(<http://forums.mozillazine.org/viewtopic.php?t=500361>), so I was prepared.

By the way, if porting MAF to SM 2.0 just would have been a question of 
changing install.rdf a bit, I wouldn't have done this request in the 
first place... :)
I did some further experimentation, but I had to give up because I 
neither know the structure of SM nor of FF nor of MAF.

As it turns out from what I read on MozillaZine, MAF is difficult to 
port to SM because it is to sophisticated - a problem a lot of software 
seems to face.

I will be glad to help you in finding bugs as an early adopter of new 
versions. Please keep in mind that I don't use all functions of MAF, so 
everyday experience will not be a systematic test.
I don't use the MHT-Format at all, and I nearly never use the mult-page 
capability, i.e. I use MAF for saving single pages only.

Ciao
Ueli

Paolo Amadini schrieb [10.11.09 14:57]:
Paolo Amadini schrieb [10.11.09 22:14]:

From paolo.01.prg at amadzone.org  Wed Nov 11 06:36:47 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Wed, 11 Nov 2009 15:36:47 +0100
Subject: [Maf] Request: Support SeaMonkey 2.0
In-Reply-To: <4AF9F031.9030504@gmx.ch>
References: <4AF928DC.9030703@gmx.ch> <4AF9714C.8090808@amadzone.org>
	<4AF9F031.9030504@gmx.ch>
Message-ID: <4AFACBFF.7070602@amadzone.org>

Ueli,

thank you very much for your active cooperation with the experiments
for running MAF on SM, and for your offer of helping by trying out
new versions; even everyday usage may be successful in finding possible
problems that my systematic tests may miss :-)

Too bad that porting to SeaMonkey is not so easy, otherwise we'd have
achieved compatibility much sooner.

Ciao,
Paolo

Ueli wrote:
> Ciao Paolo
> 
> Well, so after the good news follows some bad. :)
> I followed your discussion with Philip Chee on the Porting thread on the
> MozillaZine forums
> (<http://forums.mozillazine.org/viewtopic.php?t=500361>), so I was
> prepared.
> 
> By the way, if porting MAF to SM 2.0 just would have been a question of
> changing install.rdf a bit, I wouldn't have done this request in the
> first place... :)
> I did some further experimentation, but I had to give up because I
> neither know the structure of SM nor of FF nor of MAF.
> 
> As it turns out from what I read on MozillaZine, MAF is difficult to
> port to SM because it is to sophisticated - a problem a lot of software
> seems to face.
> 
> I will be glad to help you in finding bugs as an early adopter of new
> versions. Please keep in mind that I don't use all functions of MAF, so
> everyday experience will not be a systematic test.
> I don't use the MHT-Format at all, and I nearly never use the mult-page
> capability, i.e. I use MAF for saving single pages only.
> 
> Ciao
> Ueli



From maliz at gmx.ch  Fri Nov 20 03:17:59 2009
From: maliz at gmx.ch (Ueli)
Date: Fri, 20 Nov 2009 12:17:59 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
Message-ID: <4B067AE7.4060301@gmx.ch>

Hello

Several times an error message told me that a web page couldn't be saved 
with "Save Complete". In that cases I switched to the browser's standard 
save system temporarily.

But yesterday I had data loss with "Save Complete" without any further 
notice. It just didn't save what it should have. A test today confirmed 
the problem. With the standard save system saving went well.
Unfortunately, for privacy reasons, I can't give you the internet address.
For me it's clearly "Game over" for "Save Complete"!

Is there good documentation on:
- What does "Save Complete" try to improve over the standard save system?
- Where does it succeed, where not?
- What issues are known with "Save Complete"?
- What issues are known with the standard save system?
- What are future plans for "Save Complete"?
- What are future plans for the standard save system?

Ueli

From paolo.01.prg at amadzone.org  Fri Nov 20 10:08:18 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Fri, 20 Nov 2009 19:08:18 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B067AE7.4060301@gmx.ch>
References: <4B067AE7.4060301@gmx.ch>
Message-ID: <4B06DB12.8070803@amadzone.org>

Hello Ueli,

I'll be glad to answer your questions about the status of SC and Firefox
as much as I can, but for the problem you experienced I've not enough
information to evaluate it. I just hope that the "data loss" you mention
is not something that caused you severe damage (as the term usually
suggests), but something from which you managed to recover easily once
you discovered it.

In any case, I'm sorry you're perceiving this potential bug as a
showstopper; both Save Complete and the standard save system work
fine on most websites, but neither one can be expected to succeed
on all of them: since website authors can combine content in virtually
infinite ways, there's no way to know in advance where a save operation
will work as expected and where it won't. The existence of some content,
especially if generated dynamically by scripts, will just be ignored,
and we can't even detect it and put up an error message. Moreover, the
variability is also increased if extensions that manipulate web content
are installed in the browser.

The best thing that software authors can do is to try and improve their
work as new scenarios are discovered. In this case, if you can reproduce
the problem on a page whose address you can share, I'd be glad to have a
look and see if Save Complete could be improved accordingly. You might
also want to report any potential problem with Save Complete to Stephen
Augenstein (<https://addons.mozilla.org/firefox/user/27204>), even
though I'm not sure he's available at this time.

There's an alternative to the two existing save components, though.
This is called the "snapshot" save mode, and is already in its very
early stages of development. It has its advantages and its drawbacks.
For some background, you can read the entry in the MAF bug tracker:

<https://www.mozdev.org/bugs/show_bug.cgi?id=21009>

As for the specific information that you requested, since I'm not the
main developer of the save components, I can only give you some pointers
to where you can find more information:

> - What does "Save Complete" try to improve over the standard save
> system?

For an overview, have a look at the extension's home page, under
"More about this add-on":

<https://addons.mozilla.org/firefox/addon/4723>

> - Where does it succeed, where not?
> - What issues are known with "Save Complete"?

Here are the known issues and limitations:

<http://github.com/warhammerkid/save-complete/issues>

> - What issues are known with the standard save system?

You can try several queries on the official Bugzilla database of
Mozilla Firefox. Here is one of them:

<https://bugzilla.mozilla.org/buglist.cgi?short_desc=save%20as;bug_status=NEW;bug_status=ASSIGNED;short_desc_type=allwordssubstr;product=Firefox>

> - What are future plans for "Save Complete"?

I guess at present the efforts are concentrated in fixing bugs and
website compatibility, but you should really ask this to Stephen.

> - What are future plans for the standard save system?

I think most of the proposed features and fixes already have
an entry in Bugzilla. Maybe someone on the Firefox newsgroups
will be able to answer with more precision.

Regards,
Paolo

Ueli wrote:
> Hello
> 
> Several times an error message told me that a web page couldn't be saved
> with "Save Complete". In that cases I switched to the browser's standard
> save system temporarily.
> 
> But yesterday I had data loss with "Save Complete" without any further
> notice. It just didn't save what it should have. A test today confirmed
> the problem. With the standard save system saving went well.
> Unfortunately, for privacy reasons, I can't give you the internet address.
> For me it's clearly "Game over" for "Save Complete"!


From maliz at gmx.ch  Sat Nov 21 01:32:05 2009
From: maliz at gmx.ch (Ueli)
Date: Sat, 21 Nov 2009 10:32:05 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B06DB12.8070803@amadzone.org>
References: <4B067AE7.4060301@gmx.ch> <4B06DB12.8070803@amadzone.org>
Message-ID: <4B07B395.2090508@gmx.ch>

Ciao Paolo

Grazie per la tua lunga risposta.

I had a look at all the places you told me.
Unfortunately there are nearly no "hard" facts.
E.g. the database search of "save as" in Bugzilla returns 43 entries of 
which only 2 or 3 seem to deal with the underliying mechanisms of "Save 
as...".
The description of "Save Complete" at addons.mozilla.org makes a lot of 
promises - and that's it.

If I understand you correctly, with your new "snapshot" mode you want to 
save the output of a Java script program instead of the program and some 
partly volatile input for it.
It is not difficult to find cases where this would useful, e.g. the 
result of a database query at bugzilla - I wanted to write...

Take 
https://bugzilla.mozilla.org/buglist.cgi?short_desc=save%20as;bug_status=NEW;bug_status=ASSIGNED;short_desc_type=allwordssubstr;product=Firefox
and save it a) with "Save Complete" and b) with the standard save system.
a) does not save any bug entry, without any error report!
b) saves the bug entries.

To me, in every day use the one and most important attribute of software 
is RELIABILTY which implies ADEQUATE USER FEEDBACK and PREDICTABILITY.
That's why I can't use "Save Complete" any longer.
Your "snapshot" mode will be of use in situations where it is KNOWN IN 
ADVANCE to be superiour to the standard save system or to other methods. 
TRIAL AND ERROR is NOT AN OPTION in every day use!

The following pages could not be saved with "Save Complete", resulting 
in the error message "TypeError: extractedURI is null":
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
http://microsoft-personal-operating-systems.hostweb.com/TopicMessages/microsoft.public.windows.vista.hardware_devices/2038140/1/Default.aspx
http://www.techspot.com/vb/topic125432.html
http://club.myce.com/f86/dvd-drive-missing-205899/
http://www.raymond.cc/blog/archives/2008/08/01/a-very-tiny-tool-to-monitor-changes-in-windows-files-registry-and-processes/
http://www.vistax64.com/tutorials/63567-power-options-sleep-mode-problems.html
http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk

Regards
Ueli

Paolo Amadini schrieb [20.11.09 19:08]:

From paolo.01.prg at amadzone.org  Sat Nov 21 06:54:35 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sat, 21 Nov 2009 15:54:35 +0100
Subject: [Maf] OTHER TEST: Data loss with integrated "Save Complete"
	extension
In-Reply-To: <4b07df05.0f0bca0a.788e.57ce@mx.google.com>
References: <4B067AE7.4060301@gmx.ch> <4B06DB12.8070803@amadzone.org>
	<4B07B395.2090508@gmx.ch>
	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>
Message-ID: <4B07FF2B.2040605@amadzone.org>

Hello Ueli and Pablo,

thanks for the information and the tests! I have now enough material
to understand more about this situation. Some issues are actually
caused by limitations of Save Complete, while others are probably
due to an unusual local configuration.

So, Ueli, you've found one limitation of Save Complete, and maybe some
bugs that affect you. You're free to manage this situation as you like,
but I don't think just abandoning one save system for the other is the
best course of action. I'm afraid that if you just do that, you'll
eventually be disappointed by the browser's standard save system too.
For a real-life example, try to save <http://maf.mozdev.org/>.

Any piece of software has bugs, and the level of predictability you're
looking for will never exist; even if every single known issue and
limitation was documented, there will be always a new issue to find
out. And when you find this new issue, you may help by submitting
complete bug reports, or you may switch to another tool in the hope
that it will work better. This is up to you.

As Pablo helped to determine, some problems occur only on you machine.
I'll need some more information to track these; in particular, you
should try to run the save operation on a clean profile.

The other issue with saving the Bugzilla query result is due to a
particular server technology that sends content in multiple parts,
and this is not supported by Save Complete. I don't think we'll be
able to do something about this in the short term, but if you want
you may submit a report in the MAF bug tracker.

Regards,
Paolo

[Note: Attachments prevented some messages from reaching the list]

El^Quia wrote:
> Ueli/Paolo: Hi there ;-)
>
> Just tried
>
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&ent
> ry587275443, and:
>
http://microsoft-personal-operating-systems.hostweb.com/TopicMessages/micros
> oft.public.windows.vista.hardware_devices/2038140/1/Default.aspx, saving
> them  as maff. (both saved files are attached)
>
> I do not get any error. Did a visual comparison of original page and saved
> maff using the split browser extension
> And both look exactly the same. Can't tell about internal non visible
> differences, but visually they are equal.
>
> Using the internal save complete ext. Firefox 3.5.5 x86 on Windows 7 x64,
> unmht ext also installed (a lot of exts installed haha)
>
> Just wanted to help. Please indicate if you want me to do further tests
> Best
> Pablo

El^Quia wrote:
> Paolo/Ueli:
> Tested with:
>
>
https://bugzilla.mozilla.org/buglist.cgi?short_desc=save%20as;bug_status=NEW
> ;bug_status=ASSIGNED;short_desc_type=allwordssubstr;product=Firefox
>
> Attached:
> 1. page saved using unmht as mht (saved correctly)
> 2. Page saved as maff, both with save complete enabled and disabled, both
> files show the same difference, check the upper part of page.
>
> Best
> Pablo

Ueli wrote:
> Ciao Paolo
>
> Grazie per la tua lunga risposta.
>
> I had a look at all the places you told me.
> Unfortunately there are nearly no "hard" facts.
> E.g. the database search of "save as" in Bugzilla returns 43 entries of
> which only 2 or 3 seem to deal with the underliying mechanisms of "Save
> as...".
> The description of "Save Complete" at addons.mozilla.org makes a lot of
> promises - and that's it.
>
> If I understand you correctly, with your new "snapshot" mode you want to
> save the output of a Java script program instead of the program and some
> partly volatile input for it.
> It is not difficult to find cases where this would useful, e.g. the
> result of a database query at bugzilla - I wanted to write...
>
> Take
>
https://bugzilla.mozilla.org/buglist.cgi?short_desc=save%20as;bug_status=NEW;bug_status=ASSIGNED;short_desc_type=allwordssubstr;product=Firefox
>
> and save it a) with "Save Complete" and b) with the standard save system.
> a) does not save any bug entry, without any error report!
> b) saves the bug entries.
>
> To me, in every day use the one and most important attribute of software
> is RELIABILTY which implies ADEQUATE USER FEEDBACK and PREDICTABILITY.
> That's why I can't use "Save Complete" any longer.
> Your "snapshot" mode will be of use in situations where it is KNOWN IN
> ADVANCE to be superiour to the standard save system or to other methods.
> TRIAL AND ERROR is NOT AN OPTION in every day use!
>
> The following pages could not be saved with "Save Complete", resulting
> in the error message "TypeError: extractedURI is null":
>
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
>
>
http://microsoft-personal-operating-systems.hostweb.com/TopicMessages/microsoft.public.windows.vista.hardware_devices/2038140/1/Default.aspx
>
> http://www.techspot.com/vb/topic125432.html
> http://club.myce.com/f86/dvd-drive-missing-205899/
>
http://www.raymond.cc/blog/archives/2008/08/01/a-very-tiny-tool-to-monitor-changes-in-windows-files-registry-and-processes/
>
>
http://www.vistax64.com/tutorials/63567-power-options-sleep-mode-problems.html
>
> http://www.thinkwiki.org/wiki/BIOS_update_without_optical_disk
>
> Regards
> Ueli


From maliz at gmx.ch  Sat Nov 21 08:37:32 2009
From: maliz at gmx.ch (Ueli)
Date: Sat, 21 Nov 2009 17:37:32 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B07FF2B.2040605@amadzone.org>
References: <4B067AE7.4060301@gmx.ch>
	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>
	<4B07FF2B.2040605@amadzone.org>
Message-ID: <4B08174C.2030705@gmx.ch>

Hello Paolo and Pablo

I don't agree with you at all, Paolo.
I draw a clear distinction between important and unimportant information.

Your <http://maf.mozdev.org/> is a good example.
While the standard save system looses some information concerning 
overall style and some details of the border it is unimportant stuff. 
Some time ago Wikipedia pages saved much worse and I missed a better 
quality - but even then the main information was preserved. Now I'm 
actually impressed HOW WELL the standard save system + MAF work 
together. (Wikipedia and MAF as well were different.)
On the other hand, ironically, with "Save COMPLETE" I simply LOST 
EVERYTHING! And I even can't reconstruct it. (It was a chat log.)

It is not true that "the level of predictability you're looking for will 
never exist". I can happily live with the limitations of the standard 
save system.
I do not understand why you do such commited promotion for "Save 
Complete". Obviously, "Save Complete" is not tested very well. (more to 
follow)

Do I have an unusual local configuration?
Probably not.
It's WinXP SP3, FF 3.5.5 and the Extensions "Java Quick Starter 1.0", 
"Microsoft .NET Framework Assistant 1.1" (both installed by Firefox 
itself), and "Mozilla Archive Format 0.16.4.0".
I consider this a "clean profile".

How do you know that the problems only occur on my machine? ;)

In a different discussion it became clear that some bug in SeaMonkey is 
operating system dependent. While it occurs on Windows, it does not on 
Linux. But then someone reported that it would not occure on Windows 
Vista. It seems to happen on XP only...

The results of Pablos tests (Thank you, Pablo!) surprised me at the 
first moment. But considering all sayed they suggest that "Save 
Complete" has an operating system dependent bug which occurs on Windows 
XP. This bug could be due to a bug in an underlying function it uses.

I repeat: "Save Complete" simply isn't tested well enough!
In this point the standard save system has a huge, undeniable advantage.
It's behaviour has a higher predictability... :)

Ueli

Paolo Amadini schrieb [21.11.09 15:54]:
> Hello Ueli and Pablo,
>
> thanks for the information and the tests! I have now enough material
> to understand more about this situation. Some issues are actually
> caused by limitations of Save Complete, while others are probably
> due to an unusual local configuration.
>
> So, Ueli, you've found one limitation of Save Complete, and maybe some
> bugs that affect you. You're free to manage this situation as you like,
> but I don't think just abandoning one save system for the other is the
> best course of action. I'm afraid that if you just do that, you'll
> eventually be disappointed by the browser's standard save system too.
> For a real-life example, try to save<http://maf.mozdev.org/>.
>
> Any piece of software has bugs, and the level of predictability you're
> looking for will never exist; even if every single known issue and
> limitation was documented, there will be always a new issue to find
> out. And when you find this new issue, you may help by submitting
> complete bug reports, or you may switch to another tool in the hope
> that it will work better. This is up to you.
>
> As Pablo helped to determine, some problems occur only on you machine.
> I'll need some more information to track these; in particular, you
> should try to run the save operation on a clean profile.
>
> The other issue with saving the Bugzilla query result is due to a
> particular server technology that sends content in multiple parts,
> and this is not supported by Save Complete. I don't think we'll be
> able to do something about this in the short term, but if you want
> you may submit a report in the MAF bug tracker.
>
> Regards,
> Paolo
>
> [Note: Attachments prevented some messages from reaching the list]

From elquia.net at gmail.com  Sat Nov 21 09:05:32 2009
From: elquia.net at gmail.com (El^Quia)
Date: Sat, 21 Nov 2009 14:05:32 -0300
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B08174C.2030705@gmx.ch>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch>
Message-ID: <4b081de9.0e0bca0a.7e86.5de8@mx.google.com>

Ueli:
A bit off topic, but maybe not. First: I'm not a programmer, but my main
line of work is PC Technical Service, for end users and small business. In
that role I've seen and tried a LOT of software, mainly on All windows
variants but also on Linux (to a lesser degree). 
The point is: XP is a terribly outdated OS, from all points of view,
security, stability and compatibility. Yes I know, worldwide 60 % of PC's
are on XP, but I would suggest moving on, If your specs are adequate, to
Windows 7. Software developers will (If they haven't already) start leaving
xp behind and concentrating beta tests and soft compatibility on 7, and
hopefully x64. I agree with you that software used for work or important
stuff should be stable and tested. Usually I use a lot of beta soft, because
I like to toy around with it (grin), but on my clients pc's I NEVER install
or recommend beta stuff. Moreover: in a lot of cases I recommend older
versions, not the "latest and shiny" versions. As Americans say : "If it
ain't broke don't fix it".
Getting back on subject: I've been testing Windows 7 since the first
Technical previews came out, and I find it stable, VERY compatible with
software in general and hardware drivers, etc. You could do much worse than
trying it.

Our stuff: I'm testing maff since a long time ago, because I'm looking for a
solid, cross platform archival system. On windows I use unmht, but it does
not work on Linux, hence maff. As I KNOW it's still "beta" or not stable and
final when I do save stuff for short or long time reference I save as: maff,
mht (using unmht) and pdf (bullzip or foxit printer/driver).
I?m thinking seriously in also using djvu format, but I have not read enough
about it yet. 

Redundancy in saving info was NEVER an overkill. Better safe than sorry. :-)

I hope all this is useful for you. And I'm sure Paolo will find a way around
the problem in short time. He HAS in the past with other bugs.

Best Regards to both
Pablo

-----Original Message-----
From: maf-bounces at mozdev.org [mailto:maf-bounces at mozdev.org] On Behalf Of
Ueli
Sent: Saturday, November 21, 2009 1:38 PM
To: Paolo Amadini
Cc: maf at mozdev.org
Subject: Re: [Maf] Data loss with integrated "Save Complete" extension

Hello Paolo and Pablo

I don't agree with you at all, Paolo.
I draw a clear distinction between important and unimportant information.

Your <http://maf.mozdev.org/> is a good example.
While the standard save system looses some information concerning 
overall style and some details of the border it is unimportant stuff. 
Some time ago Wikipedia pages saved much worse and I missed a better 
quality - but even then the main information was preserved. Now I'm 
actually impressed HOW WELL the standard save system + MAF work 
together. (Wikipedia and MAF as well were different.)
On the other hand, ironically, with "Save COMPLETE" I simply LOST 
EVERYTHING! And I even can't reconstruct it. (It was a chat log.)

It is not true that "the level of predictability you're looking for will 
never exist". I can happily live with the limitations of the standard 
save system.
I do not understand why you do such commited promotion for "Save 
Complete". Obviously, "Save Complete" is not tested very well. (more to 
follow)

Do I have an unusual local configuration?
Probably not.
It's WinXP SP3, FF 3.5.5 and the Extensions "Java Quick Starter 1.0", 
"Microsoft .NET Framework Assistant 1.1" (both installed by Firefox 
itself), and "Mozilla Archive Format 0.16.4.0".
I consider this a "clean profile".

How do you know that the problems only occur on my machine? ;)

In a different discussion it became clear that some bug in SeaMonkey is 
operating system dependent. While it occurs on Windows, it does not on 
Linux. But then someone reported that it would not occure on Windows 
Vista. It seems to happen on XP only...

The results of Pablos tests (Thank you, Pablo!) surprised me at the 
first moment. But considering all sayed they suggest that "Save 
Complete" has an operating system dependent bug which occurs on Windows 
XP. This bug could be due to a bug in an underlying function it uses.

I repeat: "Save Complete" simply isn't tested well enough!
In this point the standard save system has a huge, undeniable advantage.
It's behaviour has a higher predictability... :)

Ueli

Paolo Amadini schrieb [21.11.09 15:54]:
> Hello Ueli and Pablo,
>
> thanks for the information and the tests! I have now enough material
> to understand more about this situation. Some issues are actually
> caused by limitations of Save Complete, while others are probably
> due to an unusual local configuration.
>
> So, Ueli, you've found one limitation of Save Complete, and maybe some
> bugs that affect you. You're free to manage this situation as you like,
> but I don't think just abandoning one save system for the other is the
> best course of action. I'm afraid that if you just do that, you'll
> eventually be disappointed by the browser's standard save system too.
> For a real-life example, try to save<http://maf.mozdev.org/>.
>
> Any piece of software has bugs, and the level of predictability you're
> looking for will never exist; even if every single known issue and
> limitation was documented, there will be always a new issue to find
> out. And when you find this new issue, you may help by submitting
> complete bug reports, or you may switch to another tool in the hope
> that it will work better. This is up to you.
>
> As Pablo helped to determine, some problems occur only on you machine.
> I'll need some more information to track these; in particular, you
> should try to run the save operation on a clean profile.
>
> The other issue with saving the Bugzilla query result is due to a
> particular server technology that sends content in multiple parts,
> and this is not supported by Save Complete. I don't think we'll be
> able to do something about this in the short term, but if you want
> you may submit a report in the MAF bug tracker.
>
> Regards,
> Paolo
>
> [Note: Attachments prevented some messages from reaching the list]
_______________________________________________
Maf mailing list
Maf at mozdev.org
https://www.mozdev.org/mailman/listinfo/maf


From paolo.01.prg at amadzone.org  Sun Nov 22 02:15:03 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 22 Nov 2009 11:15:03 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B08174C.2030705@gmx.ch>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch>
Message-ID: <4B090F27.1080402@amadzone.org>

Now I see what you mean, and I have to agree: with the current
limitations of the browser's standard save system, generally you
may lose the page styles but rarely the main content, while with
Save Complete, dynamically generated content is not saved, as if
the page was "reset" to its initial state. This is a severe
limitation when saving real-time chat windows, for example,
so in your case the browser's standard save system is better.

In this regard, I think the "snapshot" save mode will be able to
get the best of both worlds, allowing you to save both dynamically
generated content and page styles. It will have its share of bugs,
of course, like the other save systems, and you'll always find a
site designed in such a way that you can't save it, but in general
the new component will be able to cover more use cases than both
the other ones together.

Back to Save Complete, so far we have identified three problems:

1. Lost chat log

I guess it's dynamically generated, and unfortunately in this case
it's lost forever, but there's still a remote possibility that the
problem lies in the reconstruction of the saved pages. Did you try
to inspect the saved file with a ZIP extractor or text editor, for
MAFF and MHTML respectively, and see if the information is there?

2. "TypeError: extractedURI is null"

Neither Pablo nor I succeeded in reproducing the problem. I don't
think the bug is related to the operating system, as I also tested
on Windows XP and was able to save the page correctly. A detailed
cut-and-paste from the Error Console including a line number would
be helpful.

3. "Your browser does not support this server-push technology"

The message says it, Save Complete does not support this server-push
technology. The sites that use this technology are not so many, so
it's not an urgent issue for me. You may want to file a bug report
in Save Complete's bug tracker, or just wait for "snapshot" save.

Regards,
Paolo

Ueli wrote:
> Hello Paolo and Pablo
> 
> I don't agree with you at all, Paolo.
> I draw a clear distinction between important and unimportant information.
> 
> Your <http://maf.mozdev.org/> is a good example.
> While the standard save system looses some information concerning
> overall style and some details of the border it is unimportant stuff.
> Some time ago Wikipedia pages saved much worse and I missed a better
> quality - but even then the main information was preserved. Now I'm
> actually impressed HOW WELL the standard save system + MAF work
> together. (Wikipedia and MAF as well were different.)
> On the other hand, ironically, with "Save COMPLETE" I simply LOST
> EVERYTHING! And I even can't reconstruct it. (It was a chat log.)
> 
> It is not true that "the level of predictability you're looking for will
> never exist". I can happily live with the limitations of the standard
> save system.
> I do not understand why you do such commited promotion for "Save
> Complete". Obviously, "Save Complete" is not tested very well. (more to
> follow)
> 
> Do I have an unusual local configuration?
> Probably not.
> It's WinXP SP3, FF 3.5.5 and the Extensions "Java Quick Starter 1.0",
> "Microsoft .NET Framework Assistant 1.1" (both installed by Firefox
> itself), and "Mozilla Archive Format 0.16.4.0".
> I consider this a "clean profile".
> 
> How do you know that the problems only occur on my machine? ;)
> 
> In a different discussion it became clear that some bug in SeaMonkey is
> operating system dependent. While it occurs on Windows, it does not on
> Linux. But then someone reported that it would not occure on Windows
> Vista. It seems to happen on XP only...
> 
> The results of Pablos tests (Thank you, Pablo!) surprised me at the
> first moment. But considering all sayed they suggest that "Save
> Complete" has an operating system dependent bug which occurs on Windows
> XP. This bug could be due to a bug in an underlying function it uses.
> 
> I repeat: "Save Complete" simply isn't tested well enough!
> In this point the standard save system has a huge, undeniable advantage.
> It's behaviour has a higher predictability... :)
> 
> Ueli
> 
> Paolo Amadini schrieb [21.11.09 15:54]:
>> Hello Ueli and Pablo,
>>
>> thanks for the information and the tests! I have now enough material
>> to understand more about this situation. Some issues are actually
>> caused by limitations of Save Complete, while others are probably
>> due to an unusual local configuration.
>>
>> So, Ueli, you've found one limitation of Save Complete, and maybe some
>> bugs that affect you. You're free to manage this situation as you like,
>> but I don't think just abandoning one save system for the other is the
>> best course of action. I'm afraid that if you just do that, you'll
>> eventually be disappointed by the browser's standard save system too.
>> For a real-life example, try to save<http://maf.mozdev.org/>.
>>
>> Any piece of software has bugs, and the level of predictability you're
>> looking for will never exist; even if every single known issue and
>> limitation was documented, there will be always a new issue to find
>> out. And when you find this new issue, you may help by submitting
>> complete bug reports, or you may switch to another tool in the hope
>> that it will work better. This is up to you.
>>
>> As Pablo helped to determine, some problems occur only on you machine.
>> I'll need some more information to track these; in particular, you
>> should try to run the save operation on a clean profile.
>>
>> The other issue with saving the Bugzilla query result is due to a
>> particular server technology that sends content in multiple parts,
>> and this is not supported by Save Complete. I don't think we'll be
>> able to do something about this in the short term, but if you want
>> you may submit a report in the MAF bug tracker.
>>
>> Regards,
>> Paolo


From maliz at gmx.ch  Sun Nov 22 04:00:22 2009
From: maliz at gmx.ch (Ueli)
Date: Sun, 22 Nov 2009 13:00:22 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4b081de9.0e0bca0a.7e86.5de8@mx.google.com>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch>
	<4b081de9.0e0bca0a.7e86.5de8@mx.google.com>
Message-ID: <4B0927D6.7080802@gmx.ch>

Hello Pablo

El^Quia schrieb [21.11.09 18:05]:
> Ueli:
> A bit off topic, but maybe not. First: I'm not a programmer, but my main
> line of work is PC Technical Service, for end users and small business. In
> that role I've seen and tried a LOT of software, mainly on All windows
> variants but also on Linux (to a lesser degree).
> The point is: XP is a terribly outdated OS, from all points of view,
> security, stability and compatibility. Yes I know, worldwide 60 % of PC's

Don't exaggerate.
Don't try to frighten.

> are on XP, but I would suggest moving on, If your specs are adequate, to
> Windows 7. Software developers will (If they haven't already) start leaving
> xp behind and concentrating beta tests and soft compatibility on 7, and
> hopefully x64. I agree with you that software used for work or important

Don't suggest XP users would be some antiquated bitter-ended or diehards 
with your "moving on" and "developers start leaving xp behind".
Don't bore me with microsoftish marketing drivel.

Sorry that I have to be very clear on this.

XP is far better than you try to depict it.
I quite know some of the technological advancements in Vista or Win 7 
compared to XP (e.g. WIM and PowerShell 2). Some can be used on XP 
also... Others are good and missing and XP but not vital. And others are 
useless... (e.g. lucent window frames on Vista - the biggest rubbisch 
I've ever seen)
I'm sure most software running on Win 7 will continue to run on XP - for 
serveral years.
And concerning your love for x64: I won't need it for some time to come...

> stuff should be stable and tested. Usually I use a lot of beta soft, because
> I like to toy around with it (grin), but on my clients pc's I NEVER install
> or recommend beta stuff. Moreover: in a lot of cases I recommend older
> versions, not the "latest and shiny" versions. As Americans say : "If it
> ain't broke don't fix it".

And XP definitely IS such a case... (!!!!!)

> Getting back on subject: I've been testing Windows 7 since the first
> Technical previews came out, and I find it stable, VERY compatible with
> software in general and hardware drivers, etc. You could do much worse than
> trying it.

My notebook had Vista preinstalled. (The old Microsoft trick and 
coercion...)
I consider it better than I expected it to be by its bad reputation. But 
it is slower than XP, the explorer has drawbacks, and so on.
I will install 7 because a licence for it is included, because I love to 
toy around also (*g) and because its reputation is far better than 
Vista's one.
But on my desk machine? I won't pay for a 7 licence, and I'm not a MSDN 
subscriber as you seem to be. So I can't just try...
And I WON'T SUGGEST ANYBODY TO UPGRADE FROM XP TO 7 if he would have to 
pay for this! I won't tell him his OS would have severe deficiencies!

> Our stuff: I'm testing maff since a long time ago, because I'm looking for a
> solid, cross platform archival system. On windows I use unmht, but it does
> not work on Linux, hence maff. As I KNOW it's still "beta" or not stable and
> final when I do save stuff for short or long time reference I save as: maff,
> mht (using unmht) and pdf (bullzip or foxit printer/driver).
> I?m thinking seriously in also using djvu format, but I have not read enough
> about it yet.

Because of your attachment's I had a short look at MHT as an archival 
format again. But I want a compressed format, and so I dropped it again.
Coudn't using a windows version of Konqueror also be an option for the 
cross platform compatibility problem?

> Redundancy in saving info was NEVER an overkill. Better safe than sorry. :-)

It has drawbacks... :) (complexity, time ressources, space ressources)

> I hope all this is useful for you. And I'm sure Paolo will find a way around
> the problem in short time. He HAS in the past with other bugs.
>
> Best Regards to both
> Pablo

Ueli

From maliz at gmx.ch  Sun Nov 22 05:19:49 2009
From: maliz at gmx.ch (Ueli)
Date: Sun, 22 Nov 2009 14:19:49 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B090F27.1080402@amadzone.org>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch> <4B090F27.1080402@amadzone.org>
Message-ID: <4B093A75.5040400@gmx.ch>

Hello

Paolo Amadini schrieb [22.11.09 11:15]:
> Now I see what you mean, and I have to agree: with the current
> limitations of the browser's standard save system, generally you
> may lose the page styles but rarely the main content, while with
> Save Complete, dynamically generated content is not saved, as if
> the page was "reset" to its initial state. This is a severe
> limitation when saving real-time chat windows, for example,
> so in your case the browser's standard save system is better.

Thank you.

> In this regard, I think the "snapshot" save mode will be able to
> get the best of both worlds, allowing you to save both dynamically
> generated content and page styles. It will have its share of bugs,
> of course, like the other save systems, and you'll always find a
> site designed in such a way that you can't save it, but in general
> the new component will be able to cover more use cases than both
> the other ones together.

We'll see... :)
Please keep in mind that I consider good user feedback of success or 
failure of a saving attempt vital. (see below)

> Back to Save Complete, so far we have identified three problems:
>
> 1. Lost chat log
>
> I guess it's dynamically generated, and unfortunately in this case
> it's lost forever, but there's still a remote possibility that the
> problem lies in the reconstruction of the saved pages. Did you try
> to inspect the saved file with a ZIP extractor or text editor, for
> MAFF and MHTML respectively, and see if the information is there?

Yes, that was the first thing I did... The information wasn't there.
I even tried to recover the lost information by inspecting the browers 
cache but did not succeed. (Knowing more about the details of the cache 
could have helped or still could help.)
And the next day I did a crosscheck with an equivalent chat with the 
standard saving system and zip inspection.

At least, as a side effect, I found out that the chat seems to hide the 
use of the Jabber protocol behind some branding and proprietary chat client.
So if I could get the closed chat server to accept my own Jabber client 
I could record the log from the beginning...
Could you recommend a free Jabber client for this?

> 2. "TypeError: extractedURI is null"
>
> Neither Pablo nor I succeeded in reproducing the problem. I don't
> think the bug is related to the operating system, as I also tested
> on Windows XP and was able to save the page correctly. A detailed
> cut-and-paste from the Error Console including a line number would
> be helpful.

Intresting that you could not reproduce the error on XP.

http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
MAF 0.16.4.0, Save Complete
->
<>
Error: Save Complete reported the following errors while saving
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443:

TypeError: extractedURI is null
</>
There is no line number. Doubleklick doesn't jump anywhere.
 From loading there are a lot of warnings like
<>
Warning: Error in parsing value for 'filter'.  Declaration dropped.
Source File: 
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
Line: 1860
</>
and some messages like
<>
Security Error: Content at http://googleads.g.doubleclick.net/ may not 
load data from 
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443.
</>

> 3. "Your browser does not support this server-push technology"

I did not report this error message!
Saving the bugzilla list with SC results in SILENT loss.

You constantly seem to overlook that an important part of my complaint 
is not the fact of saving failure as is but that there is no user 
feedback of the fact.
If I had had a prominent error message (dialog window, not entry in 
error console only) of the failure of saving the chat log I immediately 
would have switched to the standard saving system and could have saved 
the chat.

> The message says it, Save Complete does not support this server-push
> technology. The sites that use this technology are not so many, so
> it's not an urgent issue for me. You may want to file a bug report
> in Save Complete's bug tracker, or just wait for "snapshot" save.

... or use the standard saving system.

Ueli

From paolo.01.prg at amadzone.org  Sun Nov 22 07:41:23 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sun, 22 Nov 2009 16:41:23 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B093A75.5040400@gmx.ch>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch> <4B090F27.1080402@amadzone.org>
	<4B093A75.5040400@gmx.ch>
Message-ID: <4B095BA3.4030706@amadzone.org>

Ueli wrote:
> Please keep in mind that I consider good user feedback of success or
> failure of a saving attempt vital.

So do I, and I'll take this into account when developing the snapshot
save mode. Just consider that sometimes there's no way for the software
to discern whether a save operation left something behind.

>> Did you try to inspect the saved file with a ZIP extractor or text
>> editor, for MAFF and MHTML respectively, and see if the information
>> is there?
> 
> Yes, that was the first thing I did... The information wasn't there.

:-(

> Could you recommend a free Jabber client

I don't know any, I'm no frequent user of instant messaging.

> http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
> Warning: Error in parsing value for 'filter'.  Declaration dropped.

I get the warnings too, they're related to the content itself, but still
can't reproduce the error. I'll have a look at the code and see if I can
find out something useful.

Regards,
Paolo

From pgaga at auracom.com  Sun Nov 22 18:17:35 2009
From: pgaga at auracom.com (Philip Griffin-Allwood)
Date: Sun, 22 Nov 2009 22:17:35 -0400
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <mailman.529.1258823157.85486.maf@mozdev.org>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>	<4B08174C.2030705@gmx.ch>
	<mailman.529.1258823157.85486.maf@mozdev.org>
Message-ID: <hecrbv$13e$1@mozdev.mozdev.org>

Sunday 22 November 2009

> On windows I use unmht, but it does
> not work on Linux,

I tested again last night and unmht does work on Linux.

Phil

From paolo.01.prg at amadzone.org  Wed Nov 25 12:07:50 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Wed, 25 Nov 2009 21:07:50 +0100
Subject: [Maf] [ANN] MAF 0.17.0 (experimental) released
Message-ID: <4B0D8E96.60107@amadzone.org>

Hello,

Mozilla Archive Format version 0.17.0 is now officially available
for download at <http://maf.mozdev.org/>.

This version is experimental (not included in automatic updates)
and greatly improves the compatibility with the MHTML format.

MAF 0.17.0 has the following user-visible improvements over MAF 0.16.4:

    * Improved performance of MHTML extraction.
    * MHTML compatibility improvements:
          o Pages generated by other browsers now always open correctly
             even if they contain multiple frames.
          o The original page title stored inside MHTML files is now
             compatible with other browsers, even when it contains
             international characters.
          o Images and other content that are not available in the
             archive are retrieved from their original location if
             possible.
          o General compatibility improvements, supporting MHTML files
             generated by a wider range of applications.

The following issues are known to exist in MAF 0.17.0:

    * In order to open MHTML files when the IE Tab extension is
       installed, the filter /^file :\/\/\/.*\.(mht|mhtml)$/ must be
       disabled from the IE Tab options.
    * The Download Sort extension has a known incompatibility with MAF.
       The conflict cannot be resolved without proper modifications to
       both extensions, and Download Sort is not actively maintained at
       this time.
    * The integrated Save Complete extension cannot always save pages
       with dynamic contents correctly.
    * When saving a page in an archive fails, retrying the download from
       the Downloads window does not achieve the expected result.
    * Opening very long documents contained inside MHTML files may cause
       the browser to stop responding temporarily.
    * With versions of Firefox prior to 3.5.3, web archive files must
       have a lowercase file name extension in order to be opened.

Regards,
Paolo Amadini


From maliz at gmx.ch  Fri Nov 27 04:36:31 2009
From: maliz at gmx.ch (maliz at gmx.ch)
Date: Fri, 27 Nov 2009 13:36:31 +0100
Subject: [Maf] Data loss with integrated "Save Complete" extension
In-Reply-To: <4B090F27.1080402@amadzone.org>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>
	<4B08174C.2030705@gmx.ch> <4B090F27.1080402@amadzone.org>
Message-ID: <4B0FC7CF.3010002@gmx.ch>

Paolo Amadini schrieb [22.11.09 11:15]:
> 2. "TypeError: extractedURI is null"
>
> Neither Pablo nor I succeeded in reproducing the problem. I don't
> think the bug is related to the operating system, as I also tested
> on Windows XP and was able to save the page correctly. A detailed
> cut-and-paste from the Error Console including a line number would
> be helpful.

I repeated the test on a different machine, in a lot of variations, with:

4 GB RAM
Vista SP 2, all security patches installed
Firefox 3.5.5
MAF 0.15.1 in the program directory or
MAF 0.16.4 in a user profile (after removing MAF from the program directory)
minimal profile (for user account freshly generated)
account with user preveleges or account with admin preveleges
firewall on or off
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443
using integrated Save Complete component
Save page as... with MAFF

Result:
I always got the error "TypeError: extractedURI is null" in the error 
console, without any pointer to a source location.

"Save Complete" opend a dialog box for error reporting with:
<Download-Fehler>
http://www.neowin.net/forum/index.php?showtopic=427449&st=30&p=587275443&entry587275443 
konnte nicht gespeichert werden, weil ein Fehler geschah.

Bitte versuchen Sie es sp?ter nochmal oder speichern Sie den Download an 
einem anderen Ort.

Weitere Informationen sind in der Fehlerkonsole verf?gbar.

Die Speicher-Operation wurde durch die "Save Complete"-Komponente 
ausgef?hrt. Wenn der Fehler weiter besteht, sollten Sie das 
Standard-Speichersystem des Browsers ben?tzen.
</Download-Fehler>

Conclusion:
Either we have a misunderstanding about further configuration of MAF and 
test conditions, or the integrated Save Complete component is dependent 
on an effect of a seemingly unrelated piece of software in the system, 
or the error arises because of coincidence and bad code quality of Save 
Complete (e.q. uninitialized variables).
Because of the dialog box of Save Complete I assume the error is trapped 
in a controlled way, not e.g. caused by a stack misalignment with 
uncontrolled break. That means that more information on the error 
context would be availabe - if Save Complete would only report it...

MAF should be made independent of Save Complete if possible at all.
If the Firefox API has pointers to the save system which transparently 
hide the actually used functions this would be the way to go.
The user would configure the save system to use outside of MAF and MAF 
would use the save system Firefox offers.

Ueli

From paolo.01.prg at amadzone.org  Sat Nov 28 02:54:47 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sat, 28 Nov 2009 11:54:47 +0100
Subject: [Maf] Save Complete URI collection bug fixed (was: Data loss with
 integrated "Save Complete" extension)
In-Reply-To: <4B0FC7CF.3010002@gmx.ch>
References: <4B067AE7.4060301@gmx.ch>	<4B06DB12.8070803@amadzone.org>	<4B07B395.2090508@gmx.ch>	<4b07df05.0f0bca0a.788e.57ce@mx.google.com>	<4B07FF2B.2040605@amadzone.org>	<4B08174C.2030705@gmx.ch>
	<4B090F27.1080402@amadzone.org> <4B0FC7CF.3010002@gmx.ch>
Message-ID: <4B110177.4080601@amadzone.org>

maliz at gmx.ch wrote:
> I repeated the test on a different machine, in a lot of variations
> Result:
> I always got the error "TypeError: extractedURI is null" in the error
> console, without any pointer to a source location.
> Conclusion:
> Either we have a misunderstanding about further configuration of MAF and
> test conditions, or the integrated Save Complete component is dependent
> on an effect of a seemingly unrelated piece of software in the system,
> or the error arises because of coincidence and bad code quality of Save
> Complete (e.q. uninitialized variables).

Thank you for taking the time for these detailed tests and reports.
I finally succeeded in reproducing the problem, and found out that the
test conditions at fault were on my side: I had the NoScript extension
installed and active. My apologies if this has caused some delay towards
the resolution and unnecessary trouble.

> Because of the dialog box of Save Complete I assume the error is trapped
> in a controlled way, not e.g. caused by a stack misalignment with
> uncontrolled break. That means that more information on the error
> context would be availabe - if Save Complete would only report it...

You're right, I verified that Save Complete eats some useful information
about the error in this case. The good news are that from code review
it emerged that the error could be triggered only by the part of Save
Complete that collects the URIs to be saved, so I could easily find
the unchecked instances of the internal URI object construction that
triggered the error.

MAF version 0.17.1 should fix the problem. You may download it here:

http://downloads.mozdev.org/maf/maf-0.17.1.0-fx.xpi

Let me know if this resolves the problem in your usual profile too.

> MAF should be made independent of Save Complete if possible at all.

Recently I decided that the "snapshot" save mode will be another
component, independent from Save Complete. If the new component proves
to be good enough, it might replace Save Complete in the future.

If I'm going to phase out Save Complete gradually, instead of adapting
it to the new use case, it's not related to any reason that may emerge
from this thread, but because of other architectural limitations and
code management considerations. Save Complete's code is well written
and maintainable (I easily maintained it in the last months without
requiring input from Stephen), but many of its functions already have
similar counterparts in the MAF code, that I wrote and know better.
Considering that Stephen doesn't have the time to share with me the
development effort at present, instead of reworking Save Complete's
architecture significantly to support the snapshot mode properly,
for me it's simpler to use what MAF already provides.

> If the Firefox API has pointers to the save system which transparently
> hide the actually used functions this would be the way to go.
> The user would configure the save system to use outside of MAF and MAF
> would use the save system Firefox offers.

Firefox already has these APIs (called nsIWebBrowserPersist) and MAF
makes use of them. Unfortunately, they don't provide all the power
that's required for generating MHTML files that are compatible with
other browsers (that's why you can't do that unless you enable Save
Complete). Moreover, Firefox will only provide one save component,
and the second part (letting the user choose a different one) is a
prerogative of extensions.

Best regards,
Paolo


From paolo.01.prg at amadzone.org  Sat Nov 28 04:58:37 2009
From: paolo.01.prg at amadzone.org (Paolo Amadini)
Date: Sat, 28 Nov 2009 13:58:37 +0100
Subject: [Maf] [ANN] MAFF specification: updates to the working draft
Message-ID: <4B111E7D.6060000@amadzone.org>

Hello,

today I made a small update to the MAFF specification. I plan to enhance
the specification periodically, adding details to the sections that need
expansion, but the main work will be in response to developer requests.

This update addresses some concerns previously raised by Bayun:
* Add list of well-known file extensions and MIME media types
* Add reserved file names for extended metadata

You can view the full changelog here:
<http://hg.mozdev.org/maf/log/tip/www/maff-specification.html>

I will not post other announcements for periodical minor updates. If you
would like to stay informed on minor specification updates, an RSS feed
of the changelog above is available for subscription:
<http://hg.mozdev.org/maf/rss-log/tip/www/maff-specification.html>

Regards,
Paolo Amadini