Bugzilla Version
2.17.1

Bugzilla Bug
40873

RFE: Save as rfc 2557 MHTML; complete webpage
in one file

Last modified: 2002-12-06
11:10

Query page
Enter new bug

Bug#:

40873
alias:

Hardware:

All DEC HP Macintosh PC SGI Sun Other

Reporter:

[email-masked] (Sean Richardson)

Product:

Browser Bugzilla Calendar CCK Chimera Directory Documentation Grendel JSS MailNews Mozilla Localizations mozilla.org NSPR
NSS Phoenix
PSM Rhino
Tech Evangelism Webtools

OS:

All Windows
3.1 Windows 95 Windows 98 Windows ME Windows 2000 Windows NT Windows XP Mac
System 7 Mac System 7.5
Mac System 7.6.1 Mac System 8.0 Mac System 8.5 Mac System 8.6 Mac System 9.x MacOS X Linux
BSDI FreeBSD
NetBSD OpenBSD AIX BeOS HP-UX IRIX Neutrino
OpenVMS OS/2
OSF/1 Solaris SunOS
other

Add CC:

Component:

Accessibility APIs BiDi Hebrew & Arabic
Bookmarks Browser-General Build Config ChatZilla Complex Text Layout Cookies DOM
Abstract Schemas DOM Core
DOM Events DOM HTML DOM
Inspector DOM Level 0
DOM Load and Save DOM Mozilla Extensions DOM Other DOM
Style DOM to Text
Conversion DOM
Traversal-Range DOM
Views and Formatting Download
Manager Editor:
Composer Editor: Core
Editor: CSS Editor Embedding: ActiveX Wrapper
Embedding: APIs Embedding: Docshell Embedding: GRE Core Embedding: GTK Widget Embedding: Mac Event Handling File Handling Form Manager Form Submission GFX Compositor Help History:
Global History:
Session Image Blocking
Image: GFX Image: Layout ImageLib Installer Installer: GRE Installer: MFCEmbed Installer: XPI Packages Installer: XPInstall Engine
Internationalization Java APIs for DOM Java APIs to WebShell Java to XPCOM Bridge Java-Implemented Plugins
JavaScript Console JavaScript Debugger JavaScript Engine Keyboard Navigation Layout Layout: Block & Inline
Layout: Floats Layout: Fonts and Text Layout: Form Controls Layout: HTML Frames Layout: Misc Code Layout: R & A Pos Layout: Tables Live Connect Localization MathML Networking Networking: Cache Networking: File Networking: FTP Networking: HTTP OJI Page Info
Parser Password Manager Plug-ins Preferences Preferences: Backend Print Preview Printing Printing: Xprint Profile Manager BackEnd Profile Manager FrontEnd
Profile Migration QuickLaunch (AKA turbo
mode) RDF Search Security:
CAPS Security:
General Selection Sidebar Skinability String Style
System SVG Tabbed Browser Talkback Themes
Tracking URL
Bar Viewer App Views ViewSource
X-remote XBL
XML XP Apps
XP Apps: Autocomplete
XP Apps: Cmd-line
Features XP Apps: Drag
and Drop XP Apps: GUI
Features XP Miscellany
XP Toolkit/Widgets XP Toolkit/Widgets: Menus
XP Toolkit/Widgets:
Trees XP
Toolkit/Widgets: XUL XPCOM XPCOM Registry XPConnect xpidl
XSLT

Version:

1.0 Branch Other Branch Trunk

CC:

[email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked]
[email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked] [email-masked]
[email-masked] [email-masked] [email-masked]
[email-masked] [email-masked] [email-masked] [email-masked]
[email-masked] [email-masked]
[email-masked] [email-masked] [email-masked] [email-masked]
Remove selected CCs

Status:

ASSIGNED

Priority:

-- P1 P2 P3 P4 P5

Resolution:

Severity:

blocker critical major
normal minor
trivial enhancement

Assigned To:

[email-masked] (Andreas M. "Clarence" Schneider)

Target
Milestone:

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 mozilla0.6
mozilla0.8 mozilla0.8.1 mozilla0.9 mozilla0.9.1 mozilla0.9.2 mozilla0.9.3 mozilla0.9.4 mozilla0.9.5 mozilla0.9.6 mozilla0.9.7 mozilla0.9.8 mozilla0.9.9 mozilla1.0 mozilla1.0.1 mozilla1.0.2 mozilla1.0.3 mozilla1.1alpha mozilla1.1beta mozilla1.1final mozilla1.2alpha mozilla1.2beta mozilla1.2final --- mozilla1.3alpha mozilla1.3beta mozilla1.4alpha mozilla1.4beta Future

QA Contact:

URL:

Flags: (Help!)

Requestee:

blocking1.3a

+ - ?

Summary:

Status Whiteboard:

Keywords:

Attachment

Type

Created

Flags

Actions

Create
a New Attachment (proposed patch, testcase, etc.)

View
All

Bug 40873 depends on:

18764
36419
98550

Show
dependency tree
Show
dependency graph

Bug 40873 blocks:

82118

Votes:

40    Show
votes for this bug    Vote
for this bug

Additional
Comments:

Leave as
ASSIGNED
Resolve
bug, changing resolution to FIXED INVALID
WONTFIX WORKSFORME
Resolve bug, mark it as duplicate of bug #
Reassign bug
to
Reassign bug to owner and QA contact of
selected component

View Bug
Activity   |   Format For
Printing

Description:

Opened: 2000-05-28 01:45

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".

------- Additional Comment #1 From
Simon Fraser 2000-05-30 10:56 -------

Editor would want to do something similar here as well, and it may well fit in
with our (as yet nonexistent) publishing plans.

------- Additional Comment #2 From
[email-masked] 2000-06-07 17:10 -------

Cool idea. I like it. But let's wait on it for awhile and ship this puppy
first.

------- Additional Comment #3 From
Charles Manske 2000-06-08 10:52
-------
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.

------- Additional Comment #4 From
R.K.Aa 2000-07-13 13:19 -------
is this a dup of bug 11632 ?

------- Additional Comment #5 From
[email-masked] 2000-07-13 16:16
-------
>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...

------- Additional Comment #6 From
Sean Richardson 2000-07-13 20:24 -------

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.

------- Additional Comment #7 From
R.K.Aa 2000-07-14 02:16 -------
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?

------- Additional Comment #8 From
Viswanath Ramachandran 2000-12-06 11:27
-------
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
Vishy

------- Additional Comment #9 From
Paul Chen 2000-12-29 14:27 -------
nav triage team:

This would be way cool, but we won't get to this for beta1, marking nsbeta1-,
adding helpwanted

------- Additional Comment #10
From Peter Lairo 2001-05-22 08:32 -------

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.

------- Additional Comment #11
From Alex Bishop 2001-05-22 10:49
-------
Removing dependancy to bug 82118 as it should be the other way round (bug 82118
depends on this bug).

------- Additional Comment #12
From Andreas M. "Clarence" Schneider 2001-07-18
22:12 -------
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.

------- Additional Comment #13
From Boris Zbarsky (vacation Dec 11 -- Jan
4) 2001-08-13 11:49 -------
*** Bug 95090 has been marked as a duplicate of this bug. ***

------- Additional Comment #14
From sairuh (se) 2001-10-09 15:05
-------
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. :)

------- Additional Comment #15
From matteo porta 2001-12-22 07:53 -------

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).

------- Additional Comment #16
From David Denis 2001-12-27 20:05
-------
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?

------- Additional Comment #17
From Boris Zbarsky (vacation Dec 11 -- Jan
4) 2002-01-25 08:40 -------
*** Bug 121793 has been marked as a duplicate of this bug. ***

------- Additional Comment #18
From [email-masked] 2002-01-28 00:22
-------
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

------- Additional Comment #19
From [email-masked] 2002-03-06 12:09
-------
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.

------- Additional Comment #20
From matteo porta 2002-03-06 15:23 -------

yes, a common file format based on mhtml is highly desirable
(at least to me :-)

------- Additional Comment #21
From [email-masked] 2002-03-08 12:00
-------
removing myself from the cc list

------- Additional Comment #22
From Ranjit Mathew 2002-03-18 00:41
-------
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.

------- Additional Comment #23
From Damian Yerrick 2002-03-18 21:32
-------
> 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.

------- Additional Comment #24
From Matti (marquee sucks more than
libpr0n) 2002-04-03 19:53 -------
*** Bug 131544 has been marked as a duplicate of this bug. ***

------- Additional Comment #25
From R.K.Aa 2002-05-01 19:06 -------

*** Bug 141650 has been marked as a duplicate of this bug. ***

------- Additional Comment #26
From matteo porta 2002-06-26 04:50 -------

this is scheduled for mozilla 1.1 alpha. is there any work going on ?
thanks.

------- Additional Comment #27
From Patrick Thompson 2002-07-12
09:10 -------
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.

------- Additional Comment #28
From [email-masked] 2002-07-12 10:35
-------
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.

------- Additional Comment #29
From Patrick Thompson 2002-07-12
10:54 -------
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.

------- Additional Comment #30
From [email-masked] 2002-07-12 11:24
-------
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.

------- Additional Comment #31
From Patrick Thompson 2002-07-12
11:32 -------
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...

------- Additional Comment #32
From [email-masked] 2002-07-12 11:38
-------
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?

------- Additional Comment #33
From Aaron Kaluszka 2002-07-12 11:47 -------

Re comment 30: It would be better to utilize the Sidebar for the tree frame.

------- Additional Comment #34
From Patrick Thompson 2002-07-12
11:55 -------
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??

------- Additional Comment #35
From [email-masked] 2002-07-12 12:04
-------
"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.

------- Additional Comment #36
From Patrick Thompson 2002-07-12
12:18 -------
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?

------- Additional Comment #37
From [email-masked] 2002-07-12 12:26
-------
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.

------- Additional Comment #38
From Patrick Thompson 2002-07-12
12:51 -------
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...

------- Additional Comment #39
From Patrick Thompson 2002-07-12
13:04 -------
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?

------- Additional Comment #40
From [email-masked] 2002-07-12 13:17
-------
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.

------- Additional Comment #41
From Bamm Gabriana 2002-07-12 19:08
-------
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?

------- Additional Comment #42
From Patrick Thompson 2002-07-12
20:24 -------
Bamm, yeah, an RFE is 'prolly the more appropriate vehicle. Now, if I only
understood how one goes about doing that?

------- Additional Comment #43
From [email-masked] 2002-07-12 20:42
-------
Just make sure Mozilla supports MHTML too. Or this will be another layer tag.

------- Additional Comment #44
From Martin Kutschker
2002-07-13 01:44 -------
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.

------- Additional Comment #45
From Patrick Thompson 2002-07-14
10:13 -------
Martin, done. It's bug 157422

------- Additional Comment #46
From Alan 2002-07-15 05:42 -------
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?

------- Additional Comment #47
From Jeremy M. Dolan 2002-07-15 13:03 -------

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.

------- Additional Comment #48
From matteo porta 2002-07-26 14:18 -------

so when this will be (finally) implemented?
please set a milestone, at least...
thanks.

------- Additional Comment #49
From Matti (marquee sucks more than
libpr0n) 2002-07-26 14:28 -------
[email-masked]: Feel free to assign it to you and attach a patch.

------- Additional Comment #50
From Matti (marquee sucks more than
libpr0n) 2002-08-13 14:14 -------
*** Bug 162549 has been marked as a duplicate of this bug. ***

Query page
Enter new bug

Actions:

New | Query | bug # |
Reports |
Requests

New Account
| Log In