Bug = 40873 - RFE: Save as rfc 2557 MHTML; complete webpage in one = file

Attachment	Type	Created	Flags	Actions
Create=20 a New Attachment (proposed patch, testcase, etc.)	View=20 All

Bug 40873 depends on:	18764=20 ~~36419=20 ~~98550=20~~~~		Sh= ow=20 dependency tree S= how=20 dependency graph
Bug 40873 blocks:	82118 =	=

Votes: =	40 Show=20 votes for this bug Vote=20 for this bug

Reassign bug to owner and QA = contact of=20 selected component
=20

View = Bug=20 Activity | Format= For=20 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=20
useful to save all of those in one file with the webpage, as an MHTML =
file.=20

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/r=
fc2557.html>,
"MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)"

This enhancement would only make sense if bug =
18764, "RFE: Full rfc2557 MHTML=20
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=20 Simon Fraser 2000-05-30 = 10:56 -------=20

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

------- Additional Comment #2 From=20 don@netscape.com 2000-06-07 = 17:10 -------=20

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

------- Additional Comment #3 From=20 Charles Manske 2000-06-08 = 10:52=20 -------

Composer already has this as a "future" bug: 36419. =
It's technically a=20
regression  relative to 4.x, and is part of publishing work. Linking =
these bugs.

------- Additional Comment #4 From=20 R.K.Aa 2000-07-13 13:19 = -------

is this a dup of bug =
11632 ?

------- Additional Comment #5 From=20 lordpixel@mac.com 2000-07-13 = 16:16=20 -------

>is this a dup of bug =
11632 ?

Kind of, but I actually this this bug is more useful, as it proposes a =
good=20
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://bugzi=
lla.mozilla.org/show_bug.cgi?id=3D41480

I'd do it but I've been told off for getting "blocks" and "depends on" =
the wrong=20
way around before. I'm not sure I understand the difference well =
enough...=20

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

It's good to have both bug =
11632, "[RFE] Save Page With Images, Stylesheets,=20
Objects, Applets" and bug =
41480, "[RFE] Support drag and drop of complex=20
selections from browser", mentioned here, but strictly there are no =
dependency=20
relationships nor any duplicate relationships among these three bugs.=20

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

Depending on those decisions, this RFE could become either a blocker or =
a=20
WONTFIX, but as all three are marked "Future", such decisions will be =
waiting
until after shipping.

------- Additional Comment #7 From=20 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 =
 save =
as'" href=3D"http://bugzilla.mozilla.org/show_bug.cgi?id=3D25756">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=20 Viswanath Ramachandran = 2000-12-06 11:27=20 -------

Since Don has left, Vishy is taking his bugs in bulk, =
pending reassignment.
thanks,
	Vishy

------- Additional Comment #9 From=20 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-,=20
adding helpwanted

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

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=20 From Alex Bishop = 2001-05-22 10:49=20 -------

Removing dependancy to bug =
82118 as it should be the other way round (bug =
82118
depends on this bug).

------- Additional Comment #12=20 From Andreas M. "Clarence" Schneider = 2001-07-18=20 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=20 From Boris Zbarsky (vacation Dec 11 = -- Jan=20 4) 2001-08-13 11:49 -------

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

------- Additional Comment #14=20 From sairuh (se) 2001-10-09 = 15:05=20 -------

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=20 From matteo porta 2001-12-22 07:53 = -------=20

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=20 From David Denis 2001-12-27 = 20:05=20 -------

saving the files as a zip is not the same, it is not an =
acceptable solution to=20
this bug.  Clarence was working on this bug awhile ago, any =
update?

------- Additional Comment #17=20 From Boris Zbarsky (vacation Dec 11 = -- Jan=20 4) 2002-01-25 08:40 -------

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

------- Additional Comment #18=20 From manko@zhurnal.ru 2002-01-28 = 00:22=20 -------

Bug =
121793 is reopened, please, discuss it, I think, this is very =
interesting
suggestion comparing with MHTML.
http://bugz=
illa.mozilla.org/show_bug.cgi?id=3D121793

------- Additional Comment #19=20 From r_rom@yahoo.com 2002-03-06 = 12:09=20 -------

IE has this option already. It uses mht extension. =
Maybe they are using MHTML=20
standard? Can anyone find out? Interoperability would useful, meaning if =

Mozilla and IE shared the same format, hopefully a standard based. Maybe =
Opera=20
would get on the bandwagon too.

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

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

------- Additional Comment #21=20 From beppe@netscape.com = 2002-03-08 12:00=20 -------

removing myself from the cc list

------- Additional Comment #22=20 From Ranjit Mathew 2002-03-18 = 00:41=20 -------

With reference to the comment made by "r_roman", IE =
does use
the MHTML format as can be seen on this page:

h=
ttp://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=20
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=20 From Damian Yerrick = 2002-03-18 21:32=20 -------

> 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=20 From Matti (marquee sucks more than=20 libpr0n) 2002-04-03 19:53 -------

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

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

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

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

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

------- Additional Comment #27=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 10:35=20 -------

Yes, yes! Those are excellent suggestions. While I have =
enjoyed IE's ability to=20
save a page along with images in one file, I didn't like the fact that=20
sometimes I had to end up with multiple files. I usually zip them up to =
have=20
just one file. Using a good file manager, like Servant Salamander=20
(http://www.altap.cz/sala=
m_en/index.html), makes working with archive files=20
very easy. You can "go into" the archive as if it were a =
folder.

------- Additional Comment #29=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 11:24=20 -------

Another alternative:
It opens in one window -- one that contains two frames. One of the =
frames=20
contains a tree with links to sections/pages. Click a link, and the =
other frame=20
loads its content.

------- Additional Comment #31=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 11:38=20 -------

That is true. But do you really want to load all pages =
at once, even if you=20
want to read one of them. Mozilla is already slow as it is, so I =
wouldn't want=20
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=20
found. Perhaps a quick pop up window (on a shortcut press) that would =
display=20
the list of pages?

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

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

------- Additional Comment #34=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 12:04=20 -------

"Then, when the saved-pages are loaded, it would open =
the "root" page and the=20
user could then decide to click the group-bookmark link to open the =
other pages=20
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=20
you load 20 (it could be many more) pages at once, much resources will =
be=20
waisted. And it will be difficult to select tabs because they would =
become=20
small if number of pages is large. You wouldn't be able to read their =
titles.

------- Additional Comment #36=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 12:26=20 -------

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=20
standard, then only Mozilla will be able to open these files, and that =
is not=20
good at all. In that case, I would probably stick with using compressed =
files.

------- Additional Comment #38=20 From Patrick Thompson = 2002-07-12=20 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=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 13:17=20 -------

Sounds good to me... if other browser wouldn't get =
confused by all this=20
additional info (flags, etc.). I haven't studied the standard, so I =
don't know=20
if it's flexible enough.

------- Additional Comment #41=20 From Bamm Gabriana 2002-07-12 = 19:08=20 -------

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=20 From Patrick Thompson = 2002-07-12=20 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=20 From r_rom@yahoo.com 2002-07-12 = 20:42=20 -------

Just make sure Mozilla supports MHTML too. Or this will =
be another layer tag.

------- Additional Comment #44=20 From Martin = Kutschker=20 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=20 From Patrick Thompson = 2002-07-14=20 10:13 -------

Martin, done. It's bug =
157422

------- Additional Comment #46=20 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=20 From Jeremy M. Dolan 2002-07-15 = 13:03 -------=20

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=20 From matteo porta 2002-07-26 14:18 = -------=20

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

------- Additional Comment #49=20 From Matti (marquee sucks more than=20 libpr0n) 2002-07-26 14:28 -------

mporta@mail.vu: Feel free to assign =
it to you and attach a patch.

------- Additional Comment #50=20 From Matti (marquee sucks more than=20 libpr0n) 2002-08-13 14:14 -------

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

Query page=20 Enter new bug =

------=_NextPart_000_0000_01C29F8E.780633C0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: http://mozilla.org/images/mozilla-banner.gif R0lGODdhWAI6AP8AAAICBPKiBP7+/P4qBP4mBAYCBCYaBJJiBOomBPomBA4CBMYeBN4iBE42BJ6e nPYmBAoCBHYSBO4mBAoGBC4GBLoeBPImBCIGBI4WBBICBM4iBBYOBNYiBIKChIoWBGoSBB4GBBIK BMIeBJYWBLp+BBYCBBIOBCYGBDoKBA4KBN6WBDYmBBoSBOIiBKYaBKIaBNoiBKoaBEpKTJIWBDYK BOYmBJ4aBEYKBNaSBD4qBE4OBG4SBBoGBMoeBGpKBAYGBEIKBNIiBF4OBG5KBLIaBFIOBCoGBEoy BHZOBH4SBGIOBHJOBK4aBC4eBLYeBGYOBL4eBB4WBDIGBHZ2dGJCBOaeBBoaHLIeBCYmJCoeBD4K BFoOBJoaBHoSBIYWBCIWBMqKBBISFE4yBBoCBEIuBJ5qBEoKBKZyBFYOBA4ODHISBC4uLEZGRKpy BN7e3L6+vO6iBGYSBLZ+BAoKDIJaBL5+BJpmBH5WBCIiJDIiBM6KBDo6PG5ubOYiBLJ6BLJ2BHp6 fE4KBEIqBCoqLIZaBFI2BOKaBIIWBNLS1GpqbJoWBB4SBLa2tI5iBFZWVDomBJ5uBJKSlIqKjK6u rIZeBLZ6BEJCRMLCxDY2NJJmBMaGBL6CBGJiZM7OzOqeBFo+BMKGBKJuBFI6BFY6BH4WBHpSBNKO BIaGhIpeBH5+fGZmZJZmBNqSBD4+PObm5OaaBNqWBE5OTFpaXPLy9DIKBK52BB4eHJaWlAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAWAI6AAAI/wABCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh1KdKgRDgSSKl3qBMJBCEpgLJ2alMEMLQUOKqBxgeGQAGDDih1LtqzZs2jT ql3Ltq3bt3Djoi1Kt67dmyUeUF0aJKvBC1D2Jg2i6MMJpwd5xEBA4IETBQq/yp1MubLly5gzp73r U4Bnzw4/g+ZMmqMGwUkTUEDYYi+DD0YWFvCSIOkCGn4T+tHMu7fv38Dflt4pWkBo0cOTWxSCOukH hCgEJ/BQQiEIBkn7fMitMAuJ4ODDi/8fH1c5zuLHP5tf/7DAadR9BZbgjqG5BSdJgFDYz2NgnNRa QDRBLeQVaOCB4bFXE3oNMajggwcVMcCEFFY4QAQCRXUCQURYOAAMaHDg4YQaDPTChBwIdEokezQ0 wW4IakbCEQQd8Z1YM9Z4Y4w8rgWhTA4uFOSPP8YwQAIixPBBDDVQmMCGI0wY20AIjHhDAVL0QICF BGwIwAwT2iCQA4gYZMYIB01QiiE9WnaAQQeM9WZBcbZpp1lEwjRkQnvmuR4EGJjh1wcJVChBCUFQ iCaVIyIAgkARPGAhF5CimNUatwyEhS0CMVBBdQYZEMqdcs1JUJ1hmToQqqS26qdLfR7/FOur7BUh qYUMVGjBowJVOeIViN0gYoU3AIAChTsIFMZAfDDyAwA6DKABqAaNAkurbqkqEKsBaAsAt9i2mVFx 5HbAEbnoPoSueh/NWpC7eq6LXIPysitkvaPVpMOtI1YoJgAn8GuoCMUKBMICFcKQQQG5HilEQQ5c EotAGAxQgw4IhbAEGOGq5YNBPoz1cUEhdxzeGVTkYYJAJuRBxRlhjYuvuRrhmy9D9aZnHL323tsz z+l6ZPPOONsMtLw3tdDviEr0OqEERCihRQaQFVSACxVqkEEEAygiwXTUGmQkAS8gZlABYnBsclkN GNTAWG0X9PbavxGyckImEBKAzDPX/2y0zuTqDPjgEOUs9N9F43v0ujZ5sPSIBMxQgK9JcGeQAkBY qMEOA1SggAhHesBrQRloMCECT1hOEBlnVEF3WIK4PVbscr/OmyGPOJQ7RkMLQPNFQ6u7rgyCH024 8IwfrvjiQfts+Ew8CPx4hQwUOqEIKBiEwgwiSF/hAzwosEPDC6hBQ38DZQADhRrooPpAG2z8eg6y i0V/7bZn1kRKvdf7e+LPAyC8CDIvAR4PcAOcSPCYFzgBJm8mXZieBK+XgYKcYIIYGEgRXOCrBwQh CEzwghdAV6EFFEEhE2DdK0x2P4LMLSwtHMgL81cZJKjEQY7on+909rsEGkQ0DkAe0f+cN0SF+PAg HThi4QqYxJ/xqYAJdJASS2K6CfaLARgYXUFONCEYYKBhFUpAHAiiABR8cYILwJhCorAEHIQrCwZZ wVjgWBA50tAyUbhhAQGgwyI+8WZTBIAMgCjEAxpxjxIJpPEGgsg/5iuKn+lhI11ihC1ZsUIEwN77 BkIBSxLAAwUoggisNyECJKErBCkACDDQpMcRoA8RQCVCCkCGTcCBVBsI1VhyWRAD3NEyKwlSH4sn kEA6QDTEIyYRDRkRRRqQkU5EiDP52LNpfoRrl6QQA4DgEC5O6IQAAEEFPNSDClTgAx9IgjnXN8EE jAAIZjvICsrgCTvxkiC+FMs9B5L/z19OJo/82+MwgUbASS7kmNF0JDOladCF8k6gCf1hQwFY0Iiu xAvZnFAM4gkAI+xHdRfw1QAsUDAIGCmjE2xBBLyEkBzsKEb7FEg/wRJTAMzUn3AJJkSj2cSbHRKQ E2WoRSXqU0f6UahFXeJQKSLMpRYzqD8dojU9grBL2sACHkgC9xjAVUu2gKtBmEEEgHABrFHoAdSK IErb6YSHzXIIrOBRTW86V5xORqfVNChUnwpUp77rM0Es5CKfSUSkKa+vR5XVXpFa0aS2pKoSJAAG SmCBjNbGQkGg1g4qu9YJImAEUzJIFNyIoAkYhAVjMW1BUGvXmOmkqQld7E4dm5BB/wJWqYklKm3/ 6tTetWu2DiUoNP1qEshOD01q7azFJLUAgqBApMqd3gsooLovmAJBzypICMaSXYJst7VgIc5sEyvb vBJ3TMjEbXB5u9vhLq8jsM0te+XrvMbStyRAeJQCODs9hYHAexl1gq9mQJDSRdeKC9CiTFVwoIN8 17XaBW94XztexgqXr+01CEIzzN712peBDYQvcAebSPNyeCQReM5+J7gFAHzgwBcSKTgFogAwwXh6 CFAjQdRWIAePxccSDkAllmCAm8SXvH6tMG4DK1jCLtOBDzzXiJ3cTBPflyQucIFAjNsvGGSlYgem wDgn1AODEOrGjyOCQSjRYIM8eP/CEQ5yWEBBhQUpWbfKnCIh1UviqF75yL81sYej+uGWeAAACyDA GBAtQQwxOroWGIMNKqRgAEgBjGi2UMEIQgcDkeAgLNjRp0/7Ujnb2coWpqh7rzwQ23ommU1+MpWR KtXFVlnQfeYzhlkNEgTQYEIZHPPjsvdo5aZo0hSqoEEkTcpMD8AFqut0gbxlU1RR2wDgkvCpEYvk E9+5IRvmtXsHvWsST5XWjSV3qql5Xo8goAcUMgI2l4YAZXMZpWgSQoUUEhVnS+t90ibPta19EGxr hrSZQbiPaAJoxXob1Q8Jd4kfnuS9NlzEuJ51rM9tEehqgBTTS5FAohTdQ1+AQhX/WAigMm0BWRYk BwYaeKoKnu24/OEIG8jMzXPelm3XOrYV5/aSJ85qH0IS4hhHrLod/vMT95pLIR9I5ko+8gk1jSEo SBSM/yVPA9kwVKj6ei9r7hZIfGEglzE72nvO8G+n+8LsdnrcmRxrP5P74lLOuKyJXmiWQHeCIgdA CSRAdQBcoAY14GhCFADm6GpZIBDgjh3JUwiElCwAlT/I5eGiAiTcbe1y6fznBeIWn/e9w3A/oqsF AOu6G/Xubveb3u3OVKSv5N5RH4jjlHtoSDn6IWhoZWclgJgXQHsgTbgleWLoQhgiZIZtUYEdVnCQ 0E+/+mvBwR1Mv+p1E7r7DpE4/99zjW4nc1y3TV86nsHPEjVkNPAA4AF/Udp7ABRgkwpRTHQJDIAO EVsgDLZ8z+d8BwF9aqECjdAE3VUQnJeAC0gQaqEHVMACNoF3b6dq5RZ+tnaBe0d7e3d+88WBHjh+ GcgSv5ZNLVA1AsE5nfUCGaEFSrNWFiAF/XchBBGA47E/BRgWOlg/bNEGdDRLbwGEClEAaKECSzB6 bWd7IqhQ7KdxGNiBr2d+GyhE6Ud+eVaFHoFpEgR/AkFCKFUDKmgRBTACACZBC6AAHdJcA9EGBQJQ cRQWcFhH2XcHi8AQRliHdygbZiEHDaCE3FeCqBeFR7Rnt1Z05dVbscc3SoeFqf+nhR1hVlZ0BX9x hhJkBhsBAh2CUjGwhgSBCgVSUzIVFqJoU2khgRTYEHmIFqjoEKsYFjjgAylAELNYgYsYdzz0hAqx enTneuUHhSGoi7LXiMAIQJLUbh4hIZf0ewSBBp3FdQXhcggxB6qwBgVxA8J2SZXFhgJxBKGIEP1U ijclFkgIiEV4hEkIEa9YB2KgWjxhgeMGYosVbs3zfcV4ekZFMz3FYUcXQCN4iIbVEgpAeFb0fwVh Y5bFTQaxA26VELIgAIiQBgZxAiSXTdwIAD9QILWoS2Cxkb1UFn5ojnwIkn8oEUZYBWWwAu7YE/CI YQhUjwpBjyFmj1L4i34WkP//SGtRlpNWuJMrsXuRRQMJAW8opQGqsy+rkRCc8AYSiRAQIARXYIkW AgU1opHgGBYeiU9jEYsemZXnuJWySIvtEQANsJKdcYuJ6I9GBZPeN4X3uGs46ZY3yZY2CZA+qRIQ MCw4NhAX8ARjmAFSuTRMYDlGMAAcwFIGsSwDYQmTMAgHkQE3gAEVIHwjwoyiUCBmORCsFQCZKRCb yY6dOZZhAZpkWBQtiYvy6FSAgDg0yZNM92cLVJPod5evWRGx6RJK0E40KBAaUAMvEAhVo29rtVEF wQQD8AAtxhBTMAuYAABWYAUIoQD7sQNJwAU9wC86BgClBh4POBAP1p0CEQIo/6mSGHGSKRma6mia aBl0avmatDmIsol+qamI9NmetVl77+USBaCXj/McAvFip1MBT0ABNvA1nIg+AkEBBOkCypYQjsAG AjEFbtAiDVECZrADTNCgeaB845EQD5YQKVCWGmGEIkorJnqidgGCFxEHEyQBQgkAChCDTlIbtCCj l9QC/ikQNECQEpAEiJkQU/AGcwAAgwChEmEHBuKhELYQItkeKPqkUDoUKnoRUNCiLwqgHqIDF8CF VgQFQMADTrGjFcIF1KUQbGCNADAFroAHABAGiQCdDMECrtNjGbOkCHF2UZqneqogU2oR/9WikAEB 2UghamB4XHpJMNADL+AEHv8iAn7JEIwwBQKBBQKQCm36BomQEJJBHqMGat/RqWmSEfi3p6RaqnqE jCLBghIkApARUh7CABV0AjbqbAjwm5uUBnyQXVjgBkNKqYAQoW4Ap/anCV6XEAYndiCRiqNqqsza rIw4kzFRpRMkAhuiA5ZUIYcAeVdwrf42UlywaQiBBclkBa0wEJLQCatzIENgrHGyriWxrM4ar/La k5AoEhcwf48jAdmDbGGUlAAgBH/XWQhwCAE7IQL6owsRCWw6EKugruwaAO5KEvA6rxRbsfPVpxiR XBO0AxAwqwNwBbkhBYN6SRLQAx6wBRV0aY+jASOwBWGDEAsrECkAHBZbszZ5Wxf26RIKkE0J4AJE aSH8NxA3IK1o+AIRQAGLVhAKMAL46iESwAT+yhCfQLM3W7VWy5JxKRNolgDJSRBaYJweUgEj8AQo 8LIIsUoeayEJkEENkQlUe7VwG7dyO7d0W7d2e7d4m7d6u7d827d++7eAG7iCO7iEGxIBAQA7 ------=_NextPart_000_0000_01C29F8E.780633C0 Content-Type: text/css; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Location: http://bugzilla.mozilla.org/css/edit_bug.css .bz_private { BACKGROUND: #f3eeee; COLOR: darkred } TABLE#flags TH { VERTICAL-ALIGN: baseline; TEXT-ALIGN: left } TABLE#flags TD { VERTICAL-ALIGN: baseline; TEXT-ALIGN: left } ------=_NextPart_000_0000_01C29F8E.780633C0--