Last Comment Bug 40873 - Save as rfc 2557 MHTML; complete webpage in one file
: Save as rfc 2557 MHTML; complete webpage in one file
Status: NEW
parity-ie
: conversion
Product: Core
Classification: Components
Component: Serializers (show other bugs)
: Trunk
: All All
: P3 enhancement with 267 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://update.mozilla.org/themes/?app...
: 95090 131544 141650 162549 209613 214382 224709 231697 241661 242280 244343 276552 285569 290938 304372 342615 1101467 (view as bug list)
Depends on: 18764 36419 98550
Blocks: 1261339 82118 169359
  Show dependency treegraph
 
Reported: 2000-05-28 01:45 PDT by Sean Richardson
Modified: 2016-08-06 21:36 PDT (History)
132 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
This page as complete MHTML (74.18 KB, text/plain)
2002-12-09 05:28 PST, Frank
no flags Details
complex frame document as MHTML archive (64.57 KB, text/plain)
2002-12-09 09:05 PST, Frank
no flags Details

Description Sean Richardson 2000-05-28 01:45:16 PDT
As an option to IE-style saving of complete webpages, including stylesheets,
images, objects, and applets, in a subdirectory (see bug 11632), it might be 
useful to save all of those in one file with the webpage, as an MHTML file. 

Quoting from the RFC:
"While initially designed to support e-mail transfer of complete
multi-resource HTML multimedia documents, these conventions can also
be employed to resources retrieved by other transfer protocols such
as HTTP and FTP to retrieve a complete multi-resource HTML multimedia
document in a single transfer or for storage and archiving of
complete HTML-documents." <URL:http://www.faqs.org/rfcs/rfc2557.html>,
"MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)"

This enhancement would only make sense if bug 18764, "RFE: Full rfc2557 MHTML 
multipart/related support in BROWSER", were also implemented, so that pages
saved as MHTML could also be viewed again! Also, implementing this feature
would imply adding .mhtml to the list in filepicker.properties (see bug 39951,
".shtml, .xhtml should be "HTML Files" in file pickers".
Comment 1 Simon Fraser 2000-05-30 10:56:35 PDT
Editor would want to do something similar here as well, and it may well fit in 
with our (as yet nonexistent) publishing plans.
Comment 2 don 2000-06-07 17:10:39 PDT
Cool idea.  I like it.  But let's wait on it for awhile and ship this puppy
first.
Comment 3 Charles Manske 2000-06-08 10:52:20 PDT
Composer already has this as a "future" bug: 36419. It's technically a 
regression  relative to 4.x, and is part of publishing work. Linking these bugs.
Comment 4 R.K.Aa. 2000-07-13 13:19:19 PDT
is this a dup of bug 11632 ?
Comment 5 Andrew Thompson 2000-07-13 16:16:51 PDT
>is this a dup of bug 11632 ?

Kind of, but I actually this this bug is more useful, as it proposes a good 
general solution. Set one up as blocking/depending on the other?

While we're on this, we should also mark a dependency between these bugs and:

http://bugzilla.mozilla.org/show_bug.cgi?id=41480

I'd do it but I've been told off for getting "blocks" and "depends on" the wrong 
way around before. I'm not sure I understand the difference well enough... 
Comment 6 Sean Richardson 2000-07-13 20:24:50 PDT
It's good to have both bug 11632, "[RFE] Save Page With Images, Stylesheets, 
Objects, Applets" and bug 41480, "[RFE] Support drag and drop of complex 
selections from browser", mentioned here, but strictly there are no dependency 
relationships nor any duplicate relationships among these three bugs. 

This bug is a feature request for a particular way of saving complete web pages 
in one file, which has its advantages. In both of the other bugs, there is no 
clear consensus that using MHTML is the best way to solve the problems they were
created for. 

Depending on those decisions, this RFE could become either a blocker or a 
WONTFIX, but as all three are marked "Future", such decisions will be waiting
until after shipping.
Comment 7 R.K.Aa. 2000-07-14 02:16:47 PDT
Perhaps 11632 should be marked dup of this one? They seem to suggest the same
improvements, but this bug (40873) has an explicit suggestion about how to
approach it.

Questions about a feature like this "comes up" a lot, people mention it on irc
etc. and are referred to these bugs. I suspect there's a handful of
"undiscovered" dups floating around as well. Thing is.. when they are scattered
around like this it's hard to get a real overview of how "hot" the topic is, but
i believe it would soon be a "mostfreq" if more collected.

There is 11632 with 3 dups, one of the dups (23027) had a dup, there is bug
25756 "[RFE] Enhanced `file-> save as'"

With this one, there are in other words at least 7 bugs till now, about what is
really the same feature request. Perhaps at least a collection bug would be an idea?
Comment 8 Viswanath Ramachandran 2000-12-06 11:27:50 PST
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Comment 9 Paul Chen 2000-12-29 14:27:12 PST
nav triage team:

This would be way cool, but we won't get to this for beta1, marking nsbeta1-, 
adding helpwanted
Comment 10 Peter Lairo 2001-05-22 08:32:11 PDT
I created a tracking (meta) bug 82118 to track these kinds of bugs and to unify
the efforts.

Maybe a few duplicates will also become aparent this way - then we can assign
the keyword MostFreq.
Comment 11 Alex Bishop 2001-05-22 10:49:16 PDT
Removing dependancy to bug 82118 as it should be the other way round (bug 82118
depends on this bug).
Comment 12 Andreas M. "Clarence" Schneider 2001-07-18 22:12:47 PDT
I'll try to implement this together with bug 18764.
This is easy to do for normal web pages, but rather hard when frames are
involved, because we have to rewrite the SRC attribute of <frame> and <iframe>
if the user has browsed within the frameset. Rewriting must be done at the
parser level, because writing a sequentialized DOM would break scripts that
change the DOM. Rewriting will suffer from the same bugs as view-source does,
but I'm about to fix many of them too (some of them are not only cosmetic).

BTW, the target milestone is for the worst case I thought about when I began to
work on bug 18764; this may be ready within the 0.9.4 timeframe, but I don't
promise anything.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2001-08-13 11:49:33 PDT
*** Bug 95090 has been marked as a duplicate of this bug. ***
Comment 14 sairuh (rarely reading bugmail) 2001-10-09 15:05:48 PDT
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Comment 15 matteo porta 2001-12-22 07:53:26 PST
since 0.9.7 is possible to save a page with its images, however
the images are saved in a folder. instead of write lot of code to
implement mhtml you can simply zip the html page and images in a
single .zip archive, like kde konqueror does (it uses a tar gzip
with the filename extension changed).
Comment 16 David Denis 2001-12-27 20:05:23 PST
saving the files as a zip is not the same, it is not an acceptable solution to 
this bug.  Clarence was working on this bug awhile ago, any update?
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2002-01-25 08:40:39 PST
*** Bug 121793 has been marked as a duplicate of this bug. ***
Comment 18 Manko 2002-01-28 00:22:13 PST
Bug 121793 is reopened, please, discuss it, I think, this is very interesting
suggestion comparing with MHTML.
http://bugzilla.mozilla.org/show_bug.cgi?id=121793
Comment 19 Roman R. 2002-03-06 12:09:27 PST
IE has this option already. It uses mht extension. Maybe they are using MHTML 
standard? Can anyone find out? Interoperability would useful, meaning if 
Mozilla and IE shared the same format, hopefully a standard based. Maybe Opera 
would get on the bandwagon too.
Comment 20 matteo porta 2002-03-06 15:23:02 PST
yes, a common file format based on mhtml is highly desirable
(at least to me :-)
Comment 21 rubydoo123 2002-03-08 12:00:07 PST
removing myself from the cc list
Comment 22 Ranjit Mathew 2002-03-18 00:41:10 PST
With reference to the comment made by "r_roman", IE does use
the MHTML format as can be seen on this page:

http://support.microsoft.com/support/kb/articles/q221/7/87.asp

or as you can find out for yourself by either opening the file
in a text editor or in Mozilla.

MHTML is indeed a very useful feature, at least for people like
me who would like to have the convenience of a single complete
document which can be rendered clearly, as opposed to the
unfriendly manner in which PDFs are rendered, at least by 
Acrobat Reader.

Therefore, it is highly desirable for Mozilla to support MHTML -
this would not result in using an MS-proprietary file format
and will actually help interoperability.

Actually I would have really liked a feature similar to what
Konquerer has (as has been pointed out) - a complete, self-
contained Web Archive, compressed, and containing related
HTML pages (e.g. a tutorial broken into chapters) and resources
like images, stylesheets, etc. Composer should be able to
produce such archives and Navigator should be able to render
them  properly.

In the interim, we should definitely have proper support for
MHTML and get rid of PDFs as much as possible!

Ranjit.
Comment 23 Damian Yerrick 2002-03-18 21:32:54 PST
> get rid of PDFs as much as possible!

Not gonna happen until Mozilla gets support for CSS paged media (bug 72321
and bug 110154).  One of the primary reasons I've seen in practice for
using PDF is not that it's all one filesystem object but rather that it
preserves page breaks, especially for forms that the user prints to paper,
fills out, and submits by mail or in person.  PDF has also been popping up
as a replacement for .ppt slides because more users have the Acrobat viewer
than the PowerPoint viewer.

Mozilla + SVG + MHTML (or the XML format discussed in bug 121793)
equals .pdf and .ppt killer.
Comment 24 Matthias Versen [:Matti] 2002-04-03 19:53:15 PST
*** Bug 131544 has been marked as a duplicate of this bug. ***
Comment 25 R.K.Aa. 2002-05-01 19:06:06 PDT
*** Bug 141650 has been marked as a duplicate of this bug. ***
Comment 26 matteo porta 2002-06-26 04:50:54 PDT
this is scheduled for mozilla 1.1 alpha. is there any work going on ?
thanks.
Comment 27 Patrick Thompson 2002-07-12 09:10:36 PDT
Its not clear from reading the above whether MHTML supports multi-page saves but
it seems to me that this should be the target for this implementation.
Specifically, while there may be a lot of single-page information pages out
there, anymore (what with all the ad stuff), many sites break their topic
content into many pages (ref. CNET or Tom's Hardware, for example.)

What is really needed is the ability for the user to enable some type of URL
recorder such that, once enabled, it will grab "clicked" links until the user
signifies the recording setup session over. At which time, Mozilla should then
traverse the saved URL list and save all pages in a self-contained file.

Also, some means should be implemented for saving the root URL withing the saved
content so that the user can easily return to the page at some later point to
see if the content has been updated.
Comment 28 Roman R. 2002-07-12 10:35:31 PDT
Yes, yes! Those are excellent suggestions. While I have enjoyed IE's ability to 
save a page along with images in one file, I didn't like the fact that 
sometimes I had to end up with multiple files. I usually zip them up to have 
just one file. Using a good file manager, like Servant Salamander 
(http://www.altap.cz/salam_en/index.html), makes working with archive files 
very easy. You can "go into" the archive as if it were a folder.
Comment 29 Patrick Thompson 2002-07-12 10:54:46 PDT
r_rom, thinking about it a bit more, Mozilla could exploit its group-bookmark
design when saving multi-page content, i.e., when the saved pages are
re-openned, each one should be openned in its own tab. In this way, saving
multi-page content would appear more like saving a book having the tabs
representing the chapters. The tabs, of course, should having the respective
page's title in the tab and expanded for mouse-over hints.
Comment 30 Roman R. 2002-07-12 11:24:30 PDT
Another alternative:
It opens in one window -- one that contains two frames. One of the frames 
contains a tree with links to sections/pages. Click a link, and the other frame 
loads its content.
Comment 31 Patrick Thompson 2002-07-12 11:32:10 PDT
The problem I see with using the "frame" paradigm is that many sites already use
them. Thus, creating a framelist for a "framed" site would be problematic and,
perhaps, a bit busy looking...
Comment 32 Roman R. 2002-07-12 11:38:56 PDT
That is true. But do you really want to load all pages at once, even if you 
want to read one of them. Mozilla is already slow as it is, so I wouldn't want 
to load more than necessary. And imaging what the UI would like with you 
suddenly got 20 tabs. I think some other way of selecting pages should be 
found. Perhaps a quick pop up window (on a shortcut press) that would display 
the list of pages?
Comment 33 Aaron Kaluszka 2002-07-12 11:47:30 PDT
Re comment 30:  It would be better to utilize the Sidebar for the tree frame.
Comment 34 Patrick Thompson 2002-07-12 11:55:24 PDT
My thought is that openning all the pages in tabs is a convenient way to show
that one, its a multipage document and two, which pages were actually saved
(versus, all the other potential links on the pages that weren't selected.)

The loading of the pages shouldn't slow it down too much since they will all be
on the local disk already. Although, maybe there could be a way to save the
group-bookmark as an embedded link during the save. Then, when the saved-pages
are loaded, it would open the "root" page and the user could then decide to
click the group-bookmark link to open the other pages as tabs??
Comment 35 Roman R. 2002-07-12 12:04:01 PDT
"Then, when the saved-pages are loaded, it would open the "root" page and the 
user could then decide to click the group-bookmark link to open the other pages 
as tabs??"

As tabs or in place of the main page.

I was talking about slowness of overall Mozilla's UI and memory consumption. If 
you load 20 (it could be many more) pages at once, much resources will be 
waisted. And it will be difficult to select tabs because they would become 
small if number of pages is large. You wouldn't be able to read their titles.

Comment 36 Patrick Thompson 2002-07-12 12:18:32 PDT
My latter suggestion (using a pseudo group-bookmark) would solve this, no? In
effect, it would load the "root" page and then allow the user to click the
embedded bookmark to expand the multi-pages into tabbed pages, if they desire.
Of course, if they choose not to, then they could still move through the saved
pages using the regular links on it.

As to the scrunched tabs, the mouse-over hint capability would allow the to see
the full titles, no?

Actually, now that I think about it, perhaps a better design would be to allow
one to save a tabbed browser window as a single file. That way, one would be
able to create tabs of disparate, yet related, articles and then save them as a
file for later offline perusal/reference?
Comment 37 Roman R. 2002-07-12 12:26:55 PDT
Yes, the pseudo group-bookmark mechanism would solve that.

Your last suggestion is not bad.

Now I have a concern. If the multiple page saving is not supported by the 
standard, then only Mozilla will be able to open these files, and that is not 
good at all. In that case, I would probably stick with using compressed files.
Comment 38 Patrick Thompson 2002-07-12 12:51:34 PDT
Hmmm, needing them to be viewed in other non-Mozilla browsers could be
problematic? Take the case where one opens several pages in a tabbed window.
Since the user can open and close tabbed pages at will, its highly likely that
the page containing the link to a tabbed page has been closed, thus, removing
the ability for one to "get" to it without a tabbed interface.

I suppose that the saving algorithm could save a TOC page containing all the
links that were saved, thus, allowing non-tabbed browsers the ability to get to
the other pages but that seems kinda kludgey to me? Perhaps it could be
implemented in such a way that only non-tab browsers are presented with this TOC???

Anyway, following through with my previous thoughts, it seems that "keying-off"
the fact that a window has tabs as the flag for multi-page saves may make the
implementation of this feature easier (rather than designing some type of
recorder on/off feature?) This would certainly be a positive extension to the
tabbed design, I think...
Comment 39 Patrick Thompson 2002-07-12 13:04:32 PDT
Here's a thought.

Mozilla saves the tabbed pages in a single file but includes a "flag" in the
file for later interrogation. Now, for non-Mozilla browsers, the file will open
with a TOC page listing the offline links contained in the saved file. However,
for Mozilla, it could detect this flag and then query whether the user wish to
open the TOC page or the root page with the others in tabs?

That way, it should be able to work with most browsers, no?
Comment 40 Roman R. 2002-07-12 13:17:21 PDT
Sounds good to me... if other browser wouldn't get confused by all this 
additional info (flags, etc.). I haven't studied the standard, so I don't know 
if it's flexible enough.
Comment 41 Bamm Gabriana 2002-07-12 19:08:17 PDT
Pat, I think Mozilla should find another way of doing this, since MHTML
is about a single document. Should this be another bug or RFE?
Comment 42 Patrick Thompson 2002-07-12 20:24:28 PDT
Bamm, yeah, an RFE is 'prolly the more appropriate vehicle. Now, if I only
understood how one goes about doing that?
Comment 43 Roman R. 2002-07-12 20:42:09 PDT
Just make sure Mozilla supports MHTML too. Or this will be another layer tag.
Comment 44 Martin Kutschker 2002-07-13 01:44:04 PDT
Pat and r_rom, this bug is about *saving* *one* html file with images and
embedded objects in one MHTML file (RFC 2557). It is not about displaying them
or creating proprietary file formats.

Please file one ore more bugs with summaries of your ideas concerning saving and
displaying multiple html files.

Note: MHTML is IMHO not built to support frames. But in theory one could create
an "envelop" of type multipart/related with the frame and the related parts
would be again of type multipart/related containg the frames. Dunno if any mail
client or browser supports this.
Comment 45 Patrick Thompson 2002-07-14 10:13:29 PDT
Martin, done. It's bug 157422
Comment 46 Alan 2002-07-15 05:42:11 PDT
If i wanted to be able to save as Mulitpart Hypertext Gzipped (.mhgz? which does
not exist AFAIK) should i file a seperate bug report / feature request?
Comment 47 Jeremy M. Dolan 2002-07-15 13:03:51 PDT
You would save it as MHTML, then type 'gzip foo.mhtml', just like for an HTML
file or anything else. Please people, the next comment should contain a patch or
some damned technical discussion on how to go about creating one.

No comment from the assignee in over a year. Removing past-due target.
Comment 48 matteo porta 2002-07-26 14:18:04 PDT
so when this will be (finally) implemented?
please set a milestone, at least...
thanks.
Comment 49 Matthias Versen [:Matti] 2002-07-26 14:28:16 PDT
mporta@mail.vu: Feel free to assign it to you and attach a patch.
Comment 50 Matthias Versen [:Matti] 2002-08-13 14:14:46 PDT
*** Bug 162549 has been marked as a duplicate of this bug. ***
Comment 51 Frank 2002-12-09 05:28:29 PST
Created attachment 108733 [details]
This page as complete MHTML
Comment 52 Frank 2002-12-09 09:05:19 PST
Created attachment 108748 [details]
complex frame document as MHTML archive

Works fine on Microsoft IE for archiving,
except some javascript specials.
Would be a useful feature for Mozilla too.
Comment 53 Collin Grady 2002-12-31 00:27:05 PST
I'm curious, is there a reason why you can't reuse the Mail/Newsgroup code for
saving email files?  From looking at a .eml file and a .mht file, they look
nearly identical, the only difference being the Return-Path and other email-only
headers.

Both save the document, along with all the images/etc stored in base64, and this
could result in a quick, simple solution.  As well, you could reuse the
Mail/Newsgroup code for viewing HTML emails for loading an MHTML file.
Comment 54 Prognathous 2003-04-17 17:35:24 PDT
Similar to Bug 18764, comment 32, MHTML support could make Composer a true BiDi
word processor for platforms that have no built-in BiDi support (e.g. BeOS, and
to a great extent, even OS X).

Prog.
Comment 55 Richard Briscoe 2003-05-19 10:57:18 PDT
Please, please implement the file saving as a single file, preferably as a standard 
compliant html archive ASAP.  This feature alone keeps me in Internet Explorer as a 
default browser.  

Could someone give a status report on this?  It has been three years since the first 
comment here and it would be useful to know whether this capability is likely to be 
implemented or a decision has been taken to not implement it.  

Comment 56 Martin Kutschker 2003-05-19 13:03:59 PDT
There is no such thing as "standard compliant html archive". I see three ways to
safe a HTML page with all related content in one file:

Safe all data in a format designed for mails: MIME type miltipart/related. This
is what this bug is about. The RFC does not define any file format (or Windows
file extension). Though if you use .mhtml IE will display it correctly. Mind
that such a file may have mail headers in it!

Another one is to store the images etc within the file using the data: protocol.
The resulting file would be standard conformeing. There is a bug filed for this
method.

The last way is to store the html file and all its part in a zip/jar archive.
Not compatible but should be much easier to implement than all the other methods.
Comment 57 Stefano Caselli 2003-05-20 11:37:24 PDT
there is already support for saving a page with images, althought it isn't a
single file. a simple solution is to write a "converter" from the format already
supported by mozilla to the .mht format used by internet explorer (and viceversa).
Comment 58 thebeastwitheyesthatstared 2003-05-31 08:20:43 PDT
What is the current status on this? I'm going to remove my vote for it as I 
keep getting more and more people just adding their email address to CC:
Comment 59 Prognathous 2003-05-31 08:48:07 PDT
The last comment by the bug assignee (Andreas M. "Clarence" Schneider) was
written almost two years ago, so I think it is safe to assume that this bug is
not going to be fixed in the foreseeable future.

Prog.
Comment 60 thebeastwitheyesthatstared 2003-05-31 09:45:27 PDT
 All respect to Andreas for his previous effort,  but this bug should be 
reassigned to somebody else, please.
Comment 61 timeless 2003-05-31 19:16:31 PDT
thank you for volunteering, please indicate when you expect to have this fixed.
if you're interested in fixing other bugs feel free to comment in them, i'll
gladly give you them too. i see you have a wide interest, that's great, i'd
suggest you limit your contributions for the time being.
Comment 62 thebeastwitheyesthatstared 2003-06-01 04:02:21 PDT
hello timeless

did you see me writing, that I was going to hack on this? Whatever it is you are
up to, this is not the way to go about it mister. I imagine and appreciate, that
you would rather see a patch attached probably, but my comment really is about
expressing my point of view.

I do not as a user or a potential developer appreciate such behavoir or
insinuendo. I help with what I can as of now, I don't need your help to tell me
what I can or what I am doing. Don't forget timeless that not everybody are alike.
Comment 63 timeless 2003-06-01 07:13:55 PDT
bugzilla is a forum for developers. we discuss patches and analyze bugs. we
don't whine about a lack of implementation nor is it proper to ask if something
is fixed or when it will be fixed. 

http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

again, if you're interested in contributing to any of the other bugs you've
touched please continue to act as you have, i have a long list and you can
certainly make it longer.
Comment 64 Thomas Stein 2003-06-07 05:29:06 PDT
I tried out Mozilla a couple of times. But the most important reason for me to 
stay with IntExp is the lack of saving web pages into a single file.
I wonder wether there is no progress on this topic for years.
It should be easy to implement this feature in comparison to other projected 
items on the todo list.

Thomas
Comment 65 Matthias Versen [:Matti] 2003-06-16 18:00:10 PDT
*** Bug 209613 has been marked as a duplicate of this bug. ***
Comment 66 Gwyn Morfey 2003-07-15 01:27:33 PDT
Is anybody interested in jointly funding a developer to implement this? Would 
anybody be able to make time available to implement it if payment were 
available? 
Comment 67 Adam Katz 2003-07-15 06:19:17 PDT
yes.  i would happily contribute $10 to such a fund.
it would have to be modelled after the amiga project,
<URL:http://www.discreetfx.com/AmiZilla.html>
and somebody would have to manage it (not me).

a note - i will not be the only contributor; 
my $10 offer stands only if the total contributions exceed $50.

additionally, i would require mhtml read/write support and ie compatibility.

this offer expires 12/2005.  void where prohibited by law (fnord).

if this becomes a popular discussion topic, we should open another bug for it
as it does not pertain to actual development.
Comment 68 Gwyn Morfey 2003-07-15 17:45:15 PDT
Okay, it looks like there's enough interest to place a bounty on this bug, but 
Bugzilla's not the place to do it. I've created a wiki to organise this effort at 
http://www.dezyne.net/codebounty. If this bug is worth something to you, please 
hit the site and add to the total. 
 
I haven't added the details/amounts of those people that emailed me, on the 
theory that it's not right to go putting other people's stuff up on the web without 
asking. 
Comment 69 Jesse Ruderman 2003-07-29 21:27:11 PDT
*** Bug 214382 has been marked as a duplicate of this bug. ***
Comment 70 thebeastwitheyesthatstared 2003-11-03 20:12:34 PST
In short: I did not ask to have this bug assigned to me, maybe you 
thought/think I did, but I didn't.

It's certainly not going to get me to contribute more, when this is the end 
result of trying to start a discussion. In short: Counter-productive.
Comment 71 Bob Firth 2003-11-05 16:22:23 PST
*** Bug 224709 has been marked as a duplicate of this bug. ***
Comment 72 Salvatore Larosa 2004-01-20 02:32:30 PST
Please look also at 

18764 	RFE: Full rfc2557 MHTML multipart/related support in BROWSER

it seems it is the same feature request...

I would like to suggest to set up such a feature for the firebird 1.0 release, 
too, because it is very important to "hardcore" net navigators and "pagesavers" 
and Opera does NOT support it ;-)
Comment 73 Christian :Biesinger (don't email me, ping me on IRC) 2004-01-20 14:16:32 PST
> it seems it is the same feature request...

no - this bug is about saving, that bug is about displaying.
Comment 74 Oleg Sidletskiy 2004-01-21 01:10:05 PST
*** Bug 231697 has been marked as a duplicate of this bug. ***
Comment 75 Richard Briscoe 2004-02-12 11:01:18 PST
Getting this "bug" fixed ought to the highest priority of the development team in my view.  

I know that I am not alone in demanding this capability of a browser.  The lack of this 
capability in Mozilla is the primary reason why Internet Explorer has not been displaced 
as the default browser in my computer.  Without this capability Mozilla (and any of the 
Mozilla derivatives will remain "nice to have", but imature and incomplete browsers 
lacking the capability of Internet Explorer.  The bug fix should also save the URL (as 
Internet Explorer does) so that a link to the page is preserved, if the page still exists, to 
check for updates to the saved item.  Just look at Internet Explorer and give Mozilla its 
capability and power!  

The lack of "votes" for this bug is merely indicative of a lack of knowledge of the bugzilla 
system by the vast majority of Mozilla users, myself included, until urged to vote for the 
bug.  The system of prioritization of bug fixes based upon such voting is a serious 
management deficiency.  The team needs to prioritize the efforts based upon some 
rational system other than this so that the efforts of the development group are not 
misguided by the sheer weight of the bureaucracy.  

There seems little explanation for why this was not accomplished a very long time ago.



  
Comment 76 alanjstr 2004-02-12 11:07:40 PST
So you think that this _enhancement_ is a higher priority than the 23243 real bugs?

There is rarely a need for a "me too" response to any bug.
Comment 77 Boris Zbarsky [:bz] (still a bit busy) 2004-02-12 11:16:41 PST
> The system of prioritization of bug fixes based upon such voting

There is no such system, actually.  Developers work on what they want to work
on, when all is said and done.

> There seems little explanation for why this was not accomplished a very long
> time ago.

Quite simply, because no one has written the code.  I'm glad to see you
volunteering.
Comment 78 Collin Grady 2004-02-12 20:41:21 PST
> > There seems little explanation for why this was not accomplished a very long
> > time ago.
> 
> Quite simply, because no one has written the code.  I'm glad to see you
> volunteering.

There isn't much to write. The code already exists in the mail client. RFC2557
files are the same format as a multi-part email message.
Comment 79 Boris Zbarsky [:bz] (still a bit busy) 2004-02-12 20:48:58 PST
Have you ever looked at the mail client code?  It's such intertangled spaghetti
that extracting a chunk of it out like this would be a pretty major
undertaking... The MIME code is _particularly_ nasty.
Comment 80 Roman R. 2004-02-12 21:43:12 PST
(In reply to comment #79)
> intertangled spaghetti... code is ...nasty.

I remember reading that that was the (or one of several?) reason the code of old
Netscape couldn't be modified to improve the software. Has this coding style
gotten into Mozilla's development too?

Comment 81 Boris Zbarsky [:bz] (still a bit busy) 2004-02-12 21:52:01 PST
Bad code happens.  It happens more in some parts of Mozilla than others.
Comment 82 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-13 06:32:54 PST
I believe the MIME handling code was basically copied verbatim from mozclassic
to mozilla... that's what it looks like, certainly.
Comment 83 Biju 2004-03-22 21:22:22 PST
I belive *.eml have and *.mht has same format.
And thunderbird can save *.eml file, and also can view *.mht and *.eml files

You can try steps at following comment
http://bugzilla.mozilla.org/show_bug.cgi?id=18764#c38

So why not take the code from messanger component. 

May be mscott or somebody from Tb team can help on this
Comment 84 Peter Panino 2004-04-02 13:53:47 PST
Saving a single web page as a single file should be implemented both in two
different ways:

1. In the generic MHTML format.
Advantage: Compatibility.

2. In a compressed format which contains the web-page elements (html, graphics,
css, etc.) in a single compressed container file. The proprietary file type
extension (e.g. ccf) should be associated to Mozilla, so when opening this file
type in the file system brings up Mozilla which internally opens the archive and
displays the original web page.
Advantage: Keeping the original files in their original state for research and
further usage.
Comment 85 Chris Carlin 2004-04-02 18:45:23 PST
<i>In a compressed format which contains the web-page elements (html, graphics,
css, etc.) in a single compressed container file.</i>

Excuse me for sticking my neck out, but wouldn't it be possible to, say, put the
compressed content inside of a mhtml file with the mimetype of gzipped, implying
that the browser should uncompress it as it would a compressed stream coming
from a compressing webserver? Or something?

With the generic nature of the mhtml file it seems like this could be done in a
relatively non-proprietary way.
Comment 86 Tim Meader 2004-04-22 10:39:28 PDT
Forgive my ignorance, but I'm wondering WHY this is seen as such an unbelievably
important feature? Where is it the case that it is absolutely required to save
an HTML page as a single file versus saving it as a page and an accompanying
folder? As a part-time web developer, if anything, I find the other method (file
+ folder) more useful since it better emulates the layout on the server. In
addition I have NEVER used IE's feature of saving as a single ".mht" file, and I
would be willing to bet that nearly 95+ percent of IE users never have either. I
just don't see the inherent (evidently overwhelming) benefit.
Comment 87 Tim Meader 2004-04-22 10:40:35 PDT
Forgive my ignorance, but I'm wondering WHY this is seen as such an unbelievably
important feature? Where is it the case that it is absolutely required to save
an HTML page as a single file versus saving it as a page and an accompanying
folder? As a part-time web developer, if anything, I find the other method (file
+ folder) more useful since it better emulates the layout on the server. In
addition I have NEVER used IE's feature of saving as a single ".mht" file, and I
would be willing to bet that nearly 95+ percent of IE users never have either. I
just don't see the inherent (evidently overwhelming) benefit.
Comment 88 Peter Panino 2004-04-22 11:26:03 PDT
(In reply to comment #86)
> In
> addition I have NEVER used IE's feature of saving as a single ".mht" file

*I* ( a professional user) use it VERY often!


> and I
> would be willing to bet that nearly 95+ percent of IE users never have either. 

*I* bet that more than 80% of IE users use this feature and find it useful.
Comment 89 Robert Parenton 2004-04-22 12:16:11 PDT
Comments 86-88:

This is not the place for this discussion.

Sorry for the bugspam everyone.
Comment 90 Richard Briscoe 2004-04-22 17:16:01 PDT
(In reply to comment #87)
> ...I'm wondering WHY this is seen as such an unbelievably
> important feature? Where is it the case that it is absolutely required to save
> an HTML page as a single file versus saving it as a page and an accompanying
> folder?


> I just don't see the inherent (evidently overwhelming) benefit.

The reason that saving the web page as a single file, at least for me and others
with whom I have communicated about this issue, is that if you place the file in
a folder or system of folders with more than one page saved per folder it
quickly becomes very cluttered trying to look for a particular subject matter. 
If you should decide to move it to a different folder there is the matter of
trying to get the correct associated folder moved with it.  It is an unnecessary
(because it can be done as a single file) and, in my opinion, undesirable
complication to have multiple files for a single web page.  

The utility of saving the URL (which none of the Mozilla project OS X browsers
do to my knowledge) is that you can click on the page and see if there is
anything new or if the page even still exists.  It also serves as useful
reminder of the web site where there may also be related information.

I use the page saving capability of IE on a daily basis to save information for
later reference in a "Filing Cabinet" which I use as a repository for these
files.  Mine is currently 12 GB in size.  That may not be much by some
standards, but it is information which is readily accessible which I find to be
sufficiently desirable that if I were forced to choose only one browser it would
be the one with this capability.  To date I have only encountered IE and iCab
which have this capability.

This is only one person's opinion, but I have encountered enough people who
either use this capability or have admitted that they miss the capability with
whatever browser they are using that I believe the number of potential users
warrants the effort.  Apart from that, it makes the browser a more powerful tool.

There are some programs which attempt to save data in a searchable format. 
Desireable though that may be I have found IE's ability to do this easily to be
 highly desireable. 

Robert Parenton,

I am sorry if you believe this is not the place for such comments, but I felt it
was appropriate to make a direct explain of why I feel the matter is important.

thebeastwitheyesthatstared,

Thanks for taking on this project!  I hope that the development team will assist
you.  I have been disappointed that the development team has not tried to get
this taken care of for so long as I feel it to be a basic capability of a
browser and now here we are going into 1.7 RC1  
Comment 91 Biju 2004-04-24 08:32:02 PDT
(In reply to comment #90 )

Alternative may be Bug#: 64286
see my example, 
goto http://snipurl.com/56pg and look your browser "Address bar"
Comment 92 Bill Mason 2004-04-25 11:06:58 PDT
*** Bug 241661 has been marked as a duplicate of this bug. ***
Comment 93 Bill Mason 2004-05-01 11:53:01 PDT
*** Bug 242280 has been marked as a duplicate of this bug. ***
Comment 94 archish 2004-05-01 17:55:08 PDT
I never knew that so many of them including me where requesting the feature. I
hope by the time FireFox version 1 rolls out we can have this feature.

thanks anyway for letting me know this was a duplicate bug.
Comment 95 João Rodrigues 2004-05-19 08:44:00 PDT
I can give yet another example on how this feature is useful.

There's a newspaper (Público <http://www.publico.pt/>) that has its articles
online only for a few days. Hence if I want to mention one of them to someone,
just sending a link isn't good enough, as later neither me nor the other person
would have access to the text on which our discussion was based on.

If the article consists only of unformatted text, I simply copy it from the
browser and paste it on the e-mail message. The recipient has access to the
article as he/she opens the e-mail message.

If it's formatted text, I select the text only version of the article, then save
it as “Web Page, HTML only” and attach the file to an e-mail message. The
recipient has access to the article by double-clicking the attachment icon
displayed in the e-mail message.

If there are images, then I just use Internet Explorer to save it as “Web
Archive, single file (*.mht)” and attach the file to an e-mail message. The
recipient has access to the article by double-clicking the attachment icon
displayed in the e-mail message.

If I were to use Mozilla, I would have to save it as “Web Page, complete,” then
create a zip file containing the HTML file plus the associated folder and attach
this compressed file to an e-mail message. The recipient has to open the e-mail
message, save the attachment, uncompress it and finally open it with a browser
in order to access the article. After viewing the article, he/she would have to
additionally delete the compressed file plus the uncompressed files.

Now you see how easier things would be if the MHTML was supported in Mozilla.
Comment 96 alanjstr 2004-05-19 09:33:24 PDT
I think that's enough "I want this too" posts.  If you have a patch, submit it.
Comment 97 Richard Briscoe 2004-05-19 10:25:49 PDT
(In reply to comment #96)
> I think that's enough "I want this too" posts.  If you have a patch, submit it.

That's the nature of voting.
Comment 98 Bill Mason 2004-05-22 02:07:17 PDT
*** Bug 244343 has been marked as a duplicate of this bug. ***
Comment 99 Kai-Uwe Rommel 2004-05-22 02:26:10 PDT
Well, I just entered a new "bug" with the same issue because I did not find this
one when searching before entering the new one.

It looks like MANY people would like to see this feature implemented. There is
(IMO) one single point that really makes the discussion about it and alternative
ways of implementation questionable: interoperability with Internet Explorer.
Face it, this is really important. And in this special case, the format is not
even MS proprietary but even open! So I think there is not much to discuss about
this. It simply is a feature that belongs to a modern browser. It is for me the
sole reason why I still keep using IE.

And because already four years are over now since the RFE has been initially
entered, it does not look like it will happen soon ...

I am offering a funding of US$ 250 if someone commits to implement it within a
time frame of half a year from now on. Please, others: don't whine and discuss
around this issue, but also offer funding in significant amounts so that we can
get this cow off the ice.
Comment 100 Karthik Sheka 2004-05-22 03:14:56 PDT
(In reply to comment #99)
[...]
> I am offering a funding of US$ 250 if someone commits to implement it within a
> time frame of half a year from now on. Please, others: don't whine and discuss
> around this issue, but also offer funding in significant amounts so that we can
> get this cow off the ice.

I'll add $100 if a this is implemented by November 22,2004 (6 months from now :-). 
Comment 101 rmjb 2004-05-22 07:42:10 PDT
If you all are serious about funding this project might I suggest you start a
project on sourcesupport.org, much like the one that was started for the browser
spellchecker: http://sourcesupport.org/?project=43.

Note, the site seems broken at this every moment, but getting this project
started and funded will add credibility to your claims.

- rmjb

Comment 102 Jesse Ruderman 2004-05-22 18:24:09 PDT
Please add your pledges to http://www.dezyne.net/codebounty instead of adding
them as Bugzilla comments.
Comment 103 Christopher Ottley 2004-07-01 06:09:37 PDT
MAF (http://maf.mozdev.org/) is an extension which might be useful.

Comment 104 Eric M. Berg 2004-09-20 14:25:15 PDT
Here's another reason that adding MHTML support to Mozilla would be a Good
Thing: MHTML is the format that OnFolio (www.onfolio.org) uses for its reports.
 As OnFolio becomes more widely used, the inability to access its reports when
using Mozilla will become more significant as a disadvantage.

(Of course, OnFolio also doesn't integrate with Mozilla when capturing
information from the Web, but that's a different problem and one that is up to
OnFolio to address.)
Comment 105 Eric M. Berg 2004-09-20 14:28:20 PDT
Here's another reason that adding MHTML support to Mozilla would be a Good
Thing: MHTML is the format that OnFolio (www.onfolio.com) uses for its reports.
 As OnFolio becomes more widely used, the inability to access its reports when
using Mozilla will become more significant as a disadvantage.

(Of course, OnFolio also doesn't integrate with Mozilla when capturing
information from the Web, but that's a different problem and one that is up to
OnFolio to address.)
Comment 106 Adam Hauner 2004-10-08 00:19:04 PDT
Just for info and inspiration:
Convert any URL to a MHTML archive using native .NET code (CodeProject)
http://www.codeproject.com/vb/net/MhtBuilder.asp
Comment 107 Ben Bucksch (:BenB) 2004-10-10 05:21:26 PDT
Adding some flames:
Microsoft loves MHT for its (appearant) DRM capabilities ("security", "trade
secrets"). US gov complains, MS defenseless because nobody else supports the format.
<http://seattlepi.nwsource.com/business/apbiz_story.asp?category=1310&slug=Microsoft%20Antitrust>
<http://www.heise.de/newsticker/meldung/52001>
Comment 108 Frank 2004-10-23 04:15:18 PDT
Did you already notice that MAF can load and save MHTML ?

http://maf.mozdev.org/

My IE-Saved files were displayed correctly and saved Files
could open in IE later.

So, the only thing to do is to integrate that basic function
into the core of Mozilla. Up to now it needs some external programs
and scripts.

Also a decision about a standard format would be nice.
I don't trust the MAFF format now, because who knows how
long this will be supported. MTHML has a disadvantage because
it's uncompressed. So a .mht.zip or .mhtz would be nice.
If this would dissapear, at least with unzipping the docs
could convert easily into the RFC-standardized MTHML.

Comment 109 Matthias Versen [:Matti] 2004-12-30 21:42:19 PST
*** Bug 276552 has been marked as a duplicate of this bug. ***
Comment 110 Greg Goss 2004-12-30 22:15:11 PST
My Bug 276552 was marked as a duplicate of this bug.  I don't see it that way,
but I think as a user, not as a developer.  It is related.  I'll accept Matti's
decision to group them together.

Bug 276552 was entered to document the fact that the installer or the "check
that Firefox is the default browser" operation didn't claim the MHT filetype. 
When I look at the file in file explorer, and doubleclick on the MHT file, IE
will open with it.  When I drag the file onto an open Firefox window, Firefox
seems to render it correctly.

I can tell XP that MHT belongs to Firefox, so this is a trivial issue, but it
affects the look'n'feel of the product to IE users who are moving to Firefox.

Separately ...
I realize it's much later than the flurry of discussions last April, but from
the viewpoint of an end user, the saved web page should be a "document".  One
document.  One item that will open with the page the way it was originally.  An
HTML and a directory of junk to support it looks like mega-clutter to an
end-user such as myself.  The airline confirmed my reservation and I wanna save
that fact.  I hit a couple of keys and save a "document" proving that I was
confirmed.  I don't want a directory of (@#$#) in such a case.  Such is the
viewpoint of a long-time IE user just arriving in Firefox.
Comment 111 Richard Briscoe 2005-02-04 07:26:09 PST
(In reply to comment #110)
> My Bug 276552 was marked as a duplicate of this bug.  I don't see it that way,
> but I think as a user, not as a developer.  It is related.  I'll accept Matti's
> decision to group them together.
> 
> Bug 276552 was entered to document the fact that the installer or the "check
> that Firefox is the default browser" operation didn't claim the MHT filetype. 
> When I look at the file in file explorer, and doubleclick on the MHT file, IE
> will open with it.  When I drag the file onto an open Firefox window, Firefox
> seems to render it correctly.
> 
> I can tell XP that MHT belongs to Firefox, so this is a trivial issue, but it
> affects the look'n'feel of the product to IE users who are moving to Firefox.
> 
> Separately ...
> I realize it's much later than the flurry of discussions last April, but from
> the viewpoint of an end user, the saved web page should be a "document".  One
> document.  One item that will open with the page the way it was originally.  An
> HTML and a directory of junk to support it looks like mega-clutter to an
> end-user such as myself.  The airline confirmed my reservation and I wanna save
> that fact.  I hit a couple of keys and save a "document" proving that I was
> confirmed.  I don't want a directory of (@#$#) in such a case.  Such is the
> viewpoint of a long-time IE user just arriving in Firefox.

The single file or document is what this bug is all about.  IE for the Mac does this (and has for a very 
long time).  Exactly as you describe, this capability is useful for keeping records of online purchases or 
simply saving web pages (which I do quite frequently).  IE does this better than any existing browser for 
the Mac, bar none.  iCab does it, but not as well.  

Just why such basic capability has been so willfully neglected by the developers remains a mystery.  In 
view of the recent downward trend in both Mozilla and Firefox releases I am not sure that it matters 
much.  I barely use either any more.  The team appears to be spending more time proclaiming how 
great Moz/FF are rather than making it so.  

Even the "bounty" placed on this seems to have attracted absolutely no attention whatsoever.  I am in 
hopes that some of the commercial browsers will do better, and soon.

Comment 112 Oomingmak 2005-02-16 04:00:14 PST
Apologies for the bug spam (as this is slightly off topic) but I may have found
a work-around that people may find useful in the interim.

http://forums.mozillazine.org/viewtopic.php?p=1237227#1237227

Thought I'd post it here as there does seem to be such a strong demand for this
functionality (if earlier comments are anything to go by).
Comment 113 Matthias Versen [:Matti] 2005-03-10 03:49:39 PST
*** Bug 285569 has been marked as a duplicate of this bug. ***
Comment 114 Smokey Ardisson (offline for a while; not following bugs - do not email) 2005-04-19 20:14:23 PDT
*** Bug 290938 has been marked as a duplicate of this bug. ***
Comment 115 Zbynek Winkler 2005-07-27 01:25:30 PDT
Maybe it would be easier to use the "data:" url scheme [1]. Firefox already
supports it and the end result of having whole page in one file would be meet.

[1] ftp://ftp.isi.edu/in-notes/rfc2397.txt
Comment 116 Paolo Tramannoni 2005-07-27 06:49:26 PDT
(In reply to comment #12)
> This is easy to do for normal web pages, but rather hard when frames are
> involved

What about doing it for simple pages only, at first? When one needs to save a
page with several frames, he can open the frame in a new window/tab, and save it
as a complete page.
In the meantime, I hope pages with frames will no longer exist in a few years.

Paolo
Comment 117 Richard Briscoe 2005-07-27 08:37:22 PDT
(In reply to comment #116)
> (In reply to comment #12)
> > This is easy to do for normal web pages, but rather hard when frames are
> > involved
> 
> What about doing it for simple pages only, at first? When one needs to save a
> page with several frames, he can open the frame in a new window/tab, and save it
> as a complete page.
> In the meantime, I hope pages with frames will no longer exist in a few years.
> 
> Paolo

If anything, it appears that web pages with frames are on the increase.  The
inability to save a page with frames (unless it was a temporary situation) would
not remedy the underlying problem.  

I remain puzzled tha IE (for OS X) has had this capability for years and the
Mozilla Foundation's leadership remains so clueless.
Comment 118 timeless 2005-07-28 09:18:46 PDT
rbriscoe@satx.rr.com: i'd like to thank you for volunteering to fix this bug.
when can we expect to see your first patch?
Comment 119 Adam Katz 2005-07-28 11:35:29 PDT
(In reply to comment #118)
> rbriscoe@satx.rr.com: i'd like to thank you for volunteering to fix this bug.
> when can we expect to see your first patch?

Josh Soref:  Your "contributions" thus far to this bug have done nothing to help
it in any positive direction.  This is the second time you have reassigned it to
an unwilling/unknowing bugzilla user.  You have done so much for Mozilla; you
should be above this.
Comment 120 Richard Briscoe 2005-07-29 05:05:22 PDT
(In reply to comment #118)
> rbriscoe@satx.rr.com: i'd like to thank you for volunteering to fix this bug.
> when can we expect to see your first patch?

Dear Whoeverthehellyouare:

I'm not a coder and neither are most of the people who are *allegely*
the target audience of the Mozilla Foundation's efforts.  

Your snide remarks have no bearing, and no merit, on the lack of
guidance by the Foundation's managers.  If you are one of them, so be
it.  If not, then it does not apply to you.  

If, as stated many times, the objective of the foundation is to produce
a better browser than IE I would have to conclude that it has only
partially met those objectives at this time.  

If you are a coder, then why don't you take a look at the bounty that
was posted earlier?  

One of the problems with the management of Mozilla is the disorganization and lack of a cohesive 
plan...roadmaps notwithstanding and people, like you, who lack the ability to think and reason, despite 
their technical skills.

If you have nothing better than your remarks to contribute to the discussion, may I respectfully suggest 
that you put your time to better use.
Comment 121 Christian Ertl 2005-07-31 05:15:48 PDT
@Richard Briscoe:
The use of HTML-FRAMEs decreases, there are statistics (at least for German
web-sites) showing this.
In XHTML 1.1 it is dropped entirely (though there will be XFRAMES as replacement).
Nevertheless I think saving frames in MHTML files should be supported.

I think this is not the place for this discussion and especially not the place
for insults.
A better place for the discussion would be forums.mozillazine.org.
Harassing developers won't help your concern.
Comment 122 Manko 2005-08-08 02:40:49 PDT
In reply to comment #115

Zbynek, see bug 121793
Comment 123 Jaime Mitchell (use bugmail@jaimem.org.uk for email) 2005-08-11 15:59:00 PDT
*** Bug 304372 has been marked as a duplicate of this bug. ***
Comment 124 Mike Connor [:mconnor] 2006-01-05 10:57:50 PST
nice-to-have, if someone comes up with a branch-safe patch (probably unlikely) we'd consider it
Comment 125 Ariel Pablo 2006-01-13 22:48:30 PST
I also think this should be added to firefox core functionality. Now there exists an extension called MAF (mozilla archive format) that is quite good, has been in development for quite some time, and the developer has been evolving it. It can save .mht and read them too, but it still fails every now and then.
Comment 126 Eriatile 2006-01-14 02:44:41 PST
Why not saving to pdf to save complete webpages? Would'nt it be more usefull and easier to implement? The bug related is bug [url=https://bugzilla.mozilla.org/show_bug.cgi?id=162659]162659[/url) and is marked as wontfix maybe it should be reconsider.
Comment 127 August Mayer 2006-01-14 03:48:19 PST
* Can't extract original HTML, CSS, JavaScript, ...
* Probably very VERY complicated to get even basic dynamic behaviour right (if at all); in MHTML, at least stuff that only works inside the page should continue to work.
* Can't display in Browser without plugin.

Also, it's possible to save as PDF already: Print, and use a PDF printer. Somebody write a nice extension around this, to provide a separate button and menu command?

(In reply to comment #126)
> Why not saving to pdf to save complete webpages?
Comment 128 Jürgen Weber 2006-01-14 08:16:34 PST
(In reply to comment #126)
> Why not saving to pdf to save complete webpages? Would'nt it be more usefull

PDF is print-page orientated, not screen orientated as HTML, the original page look gets lost, images get resized.
And to view a saved page, I want to use Firefox and not Acrobat reader (not even the reader plugin).
Comment 129 longwangx 2006-02-23 23:55:35 PST
Firefox can use xml to save page to single file (use another extension). Define a dtd to the xml. And when  firefox open the xml, then show the origin face.

And I think it will be a standard for another reader to support the file. The mht is not a standard.
Comment 130 Kai-Uwe Rommel 2006-02-24 00:17:08 PST
MHT *is* a standard - did you read the bug description?
It is RFC 2557.
Comment 131 harrylin 2006-05-09 10:32:59 PDT
Save as one .mht file (and open .mht files) is very useful to avoid clutter; for now I still need my Internet Explorer.

- But what is this stuff about MAF? Note that IE also sometimes messes up. 
- And what about saveing as .xml?! I now tried to save THIS page as .xml and it seemed to work (it's NOT yet in the save as menu!) but then I got an error message when trying to open it, both with IE and Firefox: "XML Parsing Error: mismatched tag. Expected: </link>." ...
Comment 132 Ryan Jones 2006-06-24 06:19:12 PDT
*** Bug 342615 has been marked as a duplicate of this bug. ***
Comment 133 Cees T. 2006-09-04 04:01:36 PDT
MAFF is a zipped collection of completely saved webpages.
MHT is what Thunderbird calls EML.

Firefox's complete save function misses some style stuff. Maybe that affects MAF's MHT output compared to IE's. Save Complete (https://addons.mozilla.org/firefox/2925/) should fix that.
Comment 134 Cees T. 2006-09-04 04:05:34 PDT
As for the tag error in XML: <link> tags should be <link /> tags there.
Comment 135 Frank 2006-10-11 15:29:08 PDT
I'm using the MAFF regularly
http://maf.mozdev.org/

So, many of my saved docs are now in the *.maff format.
The most important thing is to have kind of a standard. It would be a deasaster if this type of file would not be supported any more in future.

As a core functionality, this should be part of the Firefox program. As an extension there is always some trouble with upgrading. Sometimes I had an infinite-loop of spawning empty windows; at the moment it's working again. It seemed impossible to repair/workaround the Javascript Plugin. The Javascript integration in the file handlers was very chaotic. 

I would suggest a clean implementation in the Firefox core code. Just because file operations need standards and document types are the most important data structures. Web pages dissapear quickly, so archiving of interesting content is very important.
Comment 136 cprise 2006-10-11 21:39:59 PDT
The previous commenter mentions the ODF format. Ought not Firefox support ODF too? It would finally give users the benefit of a single-file archival format, and permit some added interoperability with office software.
Comment 137 Eyal Rozenberg 2006-10-12 07:03:51 PDT
(In reply to comment #136)
> The previous commenter mentions the ODF format. Ought not Firefox support ODF
> too?

Open a different bug for that, please.
Comment 138 Magnus Melin 2006-10-12 08:32:17 PDT
No need for a new one, ODF support is bug 114376.
Comment 139 cprise 2006-10-12 14:35:52 PDT
Bug 114376 is for display of ODF files.

OTOH this bug is concerned with a way to save web pages into a single file. Since ODF is standardized and spreading, I think it would make an optimal target format to satisfy the functionality requested here. IMO either MHT or ODF would be very nice to have.
Comment 140 Ian Macfarlane 2006-10-13 01:08:00 PDT
Please don't spam this bug about ODF. Yes, we want to be able to view and/or save ODF files, but this bug is about MHT (and possibly MAFF) - there already exist documents in this format, especially MHT mostly saved by IE users, and Firefox needs to be able to view these.
Comment 141 Worcester12345 2006-10-13 13:12:27 PDT
(In reply to comment #135)
> I'm using the MAFF regularly
> http://maf.mozdev.org/
Soon to be obsolete once 2.0 comes out. "MAF 0.7.0 is currently under development and will be compatible with Firefox 1.5 only."
Comment 142 Frank 2006-11-18 17:40:00 PST
> Soon to be obsolete once 2.0 comes out. "MAF 0.7.0 is currently under
> development and will be compatible with Firefox 1.5 only."
> 

No I have my problem. MAF doesn't work with 2.0, when I force to the new version it has side effects with other plugins.
Once I tried to fix MAFF, this is really a piece of spaghetti code hacking. It's not the fault of the programmer. The data format is just such a basic function, that has to be implemented in the core of Firefox. 
It's risky to save documents as MAF, because you are never sure, if you are able to read it in later versions. Microsoft has it's elegant way. Save as MHTML, it's standarized and it's supported for years.
Why don't concentrate on the most elementar things. Other features of Firefox are less important and more luxuary.
Comment 143 Jiri Znamenacek 2006-11-18 18:42:49 PST
AFAICT MAF is much safer than MHTML because you can always just unzip it and you get all files. For me it's almost the same difference as zipped OpenOffice XML files versus binary image of memory in MS Office. (Not speaking that it's smaller of course.)

But yes, Firefox should be probably able to read MHTML just to ease transition of people from IE. And as for saving - 20 years old technology invented for emails in times, when computers understood ASCII only... No, we can do better :) Internal structure of MAF file is pretty good (it remembers scroll position for example). But what we definitely need is toolkit to be able to save really ALL files in page (yes, I'm speaking about references in CSS).
Comment 144 Peter Lairo 2008-06-07 02:30:11 PDT
BTW: I lost a potential convert from IE to Firefox today because he saves
recipes from e.g., http://www.verybestbaking.com/recipes/detail.aspx?ID=18476
as MHTML files to his hard drive. Firefox can't do MHTML, and Firefox offers a silly default filename ("detail.aspx.htm"). So I lost a "customer". :-(
Comment 145 Dimitrios 2008-06-07 02:48:53 PDT
(In reply to comment #144)
You could show him how to install a free pdf printer-like driver like PrimoPdf and convert the page to pdf. Much more usable than the .mht crap which is often useless when IE fails to convert all remote images to local ones. Generally, the above tip is a very good workaround for this bug, except for pages that don't print properly or for users who don't have the slightest idea about installing printer drivers.
Comment 146 Peter Lairo 2008-06-07 03:05:47 PDT
(In reply to comment #145)
> You could show him how to install a free pdf printer-like driver 

I did, but (A) it's additional work and not what he wanted, and (B) MHTML preserves link and flexible layout and PDF doesn't. 

Also the fact that Firefox still offers some useless filename (at that site) instead of the "title" killed it for him.

> users who don't have the slightest idea about installing printer drivers.

When people blame the user for something the software should enable them to do, I stop listening.
Comment 147 Jürgen Weber 2008-06-07 03:23:52 PDT
(In reply to comment #145)
> (In reply to comment #144)
> You could show him how to install a free pdf printer-like driver like PrimoPdf

This is like some graphical artists saying in the early nineties to build websites using PDF only.
A browser is about HTML and one expects that a browser can save a HTML page and reload it at a later time. What would the users say if Openoffice couldn't save and reload a document?
Comment 148 Zbigniew Luszpinski 2008-06-07 06:14:44 PDT
This Firefox extension solves this bug:
http://www.unmht.org/unmht/en_index.html
Comment 149 Bamm Gabriana 2008-06-07 08:16:13 PDT
> You could show him how to install a free pdf printer-like driver like PrimoPdf
> and convert the page to pdf. Much more usable than the .mht crap

Why do you call a standard format RFC 2557 crap and then recommend a proprietary format PDF as its alternative?

We cheer when Firefox implements standards that IE doesn't, but when IE implements a standard that Firefox doesn't, we call it crap for the sole reason that IE popularized it?

IMHO, embracing standards and hating IE are two different things, not to be confused.
Comment 150 Richard Briscoe 2008-06-07 09:29:06 PDT
If you are on a Mac, you might want to look at how iCab 4.1.1 saves a page. Perhaps it could offer some ideas for either an add-on or change to the browser itself. It not only saves the contents of the page, but preserve the URL so that you can check a page to see if there have been changes (if the page still exits on the web). <http://www.icab.de/>
Comment 151 Justin Kerk 2008-06-07 12:00:05 PDT
(In reply to comment #146)
> (In reply to comment #145)
> Also the fact that Firefox still offers some useless filename (at that site)
> instead of the "title" killed it for him.

FWIW there's also this https://addons.mozilla.org/en-US/firefox/addon/834
Comment 152 Markus Multrus 2008-06-08 00:25:51 PDT
The latter is bug 254139 (File | Save Page As should default to <title>, not filename)
Comment 153 Zbigniew Luszpinski 2008-06-08 19:59:00 PDT
Comment #151 from Justin Kerk:
> FWIW there's also this https://addons.mozilla.org/en-US/firefox/addon/834

This extension uses IE to save MHT file == works only on Windows platform.

The unmht extension I wrote about:
http://www.unmht.org/unmht/en_index.html
is multiplatform. Works very well on my Linux.
That is why I think it fully resolves this issue.
Comment 154 Patrick Thompson 2008-06-08 20:11:43 PDT
Personally, since I have IE-Tab installed, I simply reload the page in IE-mode and then use the File>Save_Page_As menu from there to have the trident engine save it as an *.mht file.

fwiw
Comment 155 Justin Kerk 2008-06-09 07:57:15 PDT
(In reply to comment #153)
> Comment #151 from Justin Kerk:
> > FWIW there's also this https://addons.mozilla.org/en-US/firefox/addon/834
> 
> This extension uses IE to save MHT file == works only on Windows platform.

Uh, no? It has nothing to do with MHT, just the default Save As filename.
Comment 156 :aceman 2008-10-03 10:43:06 PDT
As there is no assignee on this bug, I allowed myself to change the component from 'file handling' to 'serializers' as that seemed to better fit the bug. I apologize if I am mistaken.
Comment 157 Mardeg 2009-08-08 23:19:34 PDT
*** Bug 509285 has been marked as a duplicate of this bug. ***
Comment 158 Wladimir Palant 2009-11-26 23:20:29 PST
I found this Microsoft patent: http://www.patentstorm.us/patents/6886132.html
I guess it rules out MHTML support in other browsers?
Comment 159 Wladimir Palant 2009-11-26 23:41:39 PST
Oh well, I guess I misunderstood the patent. There is a clarification here: http://www.informationweek.com/news/global-cio/showArticle.jhtml?articleID=162100345
Comment 160 Neil Parks 2010-11-19 07:11:05 PST
(In reply to comment #153)
> The unmht extension I wrote about:
> http://www.unmht.org/unmht/en_index.html
> is multiplatform. Works very well on my Linux.
> That is why I think it fully resolves this issue.

I have tried UnMHT (using Win XP).  Works very nicely. 

I am withdrawing my vote for this bug because I agree that the issue is resolved.
Comment 161 Marco Castelluccio [:marco] 2011-08-27 18:05:19 PDT
Can't we incorporate UnMHT in Firefox itself?
Comment 162 :Gijs Kruitbosch 2014-11-19 02:56:20 PST
*** Bug 1101467 has been marked as a duplicate of this bug. ***
Comment 163 ajf 2015-08-25 08:00:29 PDT
Worth noting that Google Chrome's had support for this (albeit hidden behind about:flags) since version 25, released in February 2013.
Comment 164 Leon 2015-09-25 15:52:56 PDT
Basic information about .mht file should also be automatically added within each saved .mht file. So when user would open previously saved .mht file, there would be a "notification bar" on top of that opened offline webpage with:
- saved file name info (for example: page.mht)
- saving time and date
- original webpage link (URL source), from which the .mht file was saved

This functionality is already offered by the UnMHT add-on (among the others). But the new signed version doesn't work properly anymore. Nevertheless, this should be integrated in the browser by default, because it is probably the most useful way of saving the whole webpage in one file.
Comment 165 juan.lanus 2015-12-06 06:40:28 PST
IMO this should be a mainstream document format, instead of being hidden behind an add-on in ff or a flag in chrome, and this bug is quite important. 
Like for example to make HTML so pervasive it replaces Word docs. 
Currently HTML is the most used format in the world, but for the vast majority of the world population it is read-only. 
HTML is impractical as a document format in that it requires at least to throw a bunch of files in a directory, while doc or odt are single files. This is a real issue for most people. 
MHTML solves this issue and moreover, it has the potential to store not one but several documents (pages) in a single archive file, brilliantly allowing hyperlinks among them, including deep links to # parts. 
Additionally, (M)HTML documents can be made responsive, which turned out to be !important nowadays, saving users the hideous per-line horizontal scrolling of so many docs and pdfs. 
To complete the picture, it would be excellent to have a WYSIWYG editor available, like for example w3c's Amaya http://www.w3.org/Amaya/ (not mantained since 2012). 
This particular editor's paradigm departs from the usual word-like UIs in that it fosters the structure over the form; I think this is the way for the future (like ff overcoming IE). 
Amaya could be reimplemented in JS with ease, enabling ff as an editor (like Netscape). 
With some JS magic this would allow normal people to use HTML for text docs, but also slides and why not tables with some custom calculations. 

Normal people (non-IT) should be able to attach public web pages either as links and local pages as MHTML attachments, download them and being able to open, edit and resend said pages as single files. 
The line that divides could storage and web hosting should blur.
Comment 166 ajf 2015-12-10 13:14:55 PST
On what grounds was this marked as WONTFIX?
Comment 167 Eyal Rozenberg 2015-12-10 13:37:22 PST
(In reply to ajf from comment #166)
On the grounds that they don't really care to explain themselves to us. Like many other decisions and lack-of-decisions over the past several years. Sorry for sounding bitter but - you really should not be so surprised.
Comment 168 juan.lanus 2015-12-10 14:33:41 PST
On the ground of Redmond?

Note You need to log in before you can comment on or make changes to this bug.