MHTML Format - Web Archive Files - Standard not supported in Firefox
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Won't Fix
|
Medium
|
|||
firefox (Ubuntu) |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: firefox-3.0
this location http://
displays
This document is a Web archive file. If you are seeing this message, this means your browser or editor doesn't support Web archive files. For more information on the Web archive format, go to http://
I am using ubuntu 8.04
ProblemType: Bug
Architecture: i386
Date: Sun Jun 15 10:28:40 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelMo
Package: firefox-3.0 3.0~rc1+
PackageArchitec
ProcEnviron:
PATH=/
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-18-generic i686
WORKAROUND <Thanks Thomas>:
http://
In Mozilla Bugzilla #18764, Leger-formerly-netscape (leger-formerly-netscape) wrote : | #2 |
Bulk move of all Necko (to be deleted component) bugs to new Networking
component.
In Mozilla Bugzilla #18764, Gagan-formerly-netscape (gagan-formerly-netscape) wrote : | #3 |
->ruslan
In Mozilla Bugzilla #18764, Ruslan-formerly-netscape (ruslan-formerly-netscape) wrote : | #4 |
I don't know how easy it'll be implement. Basically when we open the channel -
we would ask for /foo.html. If that contains 3 htmls, but not one - we'll have
to invent a way to deal with it.
In Mozilla Bugzilla #18764, Ruslan-formerly-netscape (ruslan-formerly-netscape) wrote : | #5 |
Per warren's decision -> nobody
In Mozilla Bugzilla #18764, Leger-formerly-netscape (leger-formerly-netscape) wrote : | #6 |
Putting on [nsbeta2-] radar.
In Mozilla Bugzilla #18764, L. David Baron (dbaron) wrote : | #7 |
Marking helpwanted since that's what I think was meant by "-> nobody".
In Mozilla Bugzilla #18764, Benc-meer (benc-meer) wrote : | #8 |
Open Networking bugs, qa=tever -> qa to me.
In Mozilla Bugzilla #18764, Peter-lairo (peter-lairo) wrote : | #9 |
This sounds like it would be a MAJOR step toward being able to save (and send)
entire HTML pages as ONE file to disk - great.
Suggest keyword: mozilla0.9.2
In Mozilla Bugzilla #18764, Peter-lairo (peter-lairo) wrote : | #10 |
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.
In Mozilla Bugzilla #18764, Alex-mozillazine (alex-mozillazine) wrote : | #11 |
In Mozilla Bugzilla #18764, C-c07 (c-c07) wrote : | #12 |
I'll try to implement this, but I do not know yet if I really have the skills
to do it. Be prepared that I may have to give this back to <email address hidden>.
My plan is roughly this:
- Implement a mhtml: protocol handler similar to the jar: handler.
- Implement a stream converter similar to the multipart/
- Implement a method to control pending loads.
The stream converter would return the root resource within a mhtml channel and
put the other parts into a cache. On every page load we'd have to check if the
referring URI has a mhtml scheme and if so, translate the URI to be loaded into
a mhtml: URI.
The mhtml channel would simply fetch from cache if the requested resource is
available. If the containing multipart resource is still loading, it would
wait until it becomes available. If the requested resource wasn't included in
the multipart resource, try to get it using the original URI.
If the requested resource isn't in the cache and the containing multipart
resource is not currently loading, we'd have to load it using basically the same
mechanism the stream converter is using.
In Mozilla Bugzilla #18764, C-c07 (c-c07) wrote : | #13 |
Assign to myself, not nobody.
In Mozilla Bugzilla #18764, Ian-hixie (ian-hixie) wrote : | #14 |
Why do you need a new protocol handler? If I go to
http://
...I would want it to display right without changing the URI.
BTW, if you _do_ use your own protocol, then it should be called 'moz-mhtml' o
whatever, so as not to polute the protocol namespace.
In Mozilla Bugzilla #18764, C-c07 (c-c07) wrote : | #15 |
Ian, somehow we must remember that we have an MHTML document if we don't want to
rewrite its links. URIs in MHTML documents can be the same as existing URIs
outside the MHTML document. If we rewrite the links (e.g. convert them to <cid:>
URIs) it is very likely that we break at least some JS.
It may be possible to keep the original URI for the root resource, but it would
require more changes to docshell. I do not intend to implement this in the first
step. Please file a bug on it once MHTML works.
If we display a resource other than the root resource (e.g. open a frame in a
new window), it does not make sense to keep the original URI and it does not
make sense to show the given URI, because the displayed document may be
different from a document with the same URI retrieved directly over the net.
Another approach would be to generate a Content-ID ourselves if the MHTML
document doesn't specify it and use <cid:> instead of <mhtml:>. But that would
be much more difficult to implement.
Name of the protocol: We do already pollute the protocol namespace (<jar:>,
<view-source:>, <about:>, <internal:>, <chrome:>, <resource:>, <javascript:>).
But if you think we shouldn't continue this it would be no problem to use
<moz-mhtml:>.
In Mozilla Bugzilla #18764, C-c07 (c-c07) wrote : | #16 |
A clarification: If http://
multipart/related you could of course type that URI into the URL bar or use it
in a link. But it would then change to
mhtml:http://
mhtml:http://
(if the root resource has Content-Location: http://
This is similar to an HTTP redirection.
In Mozilla Bugzilla #18764, Sidr (sidr) wrote : | #17 |
Clarence, first, thanks for giving this a try. From a quick look at my inbox,
at least some HTML mail uses multipart/related, instead of multipart/mixed,
so MailNews may already have some of the code you need.
As a start, try this LXR query:
http://
and especially look at
http://
and following, where <email address hidden> has some implementation notes about
how to handle multipart/related data.
In Mozilla Bugzilla #18764, C-c07 (c-c07) wrote : | #18 |
I know the MHTML code for mail. But I think it needs nearly a complete rewrite
to work outside of mail and to support all HTML features (e.g. frames).
The first implementation note in mimemrel.cpp describes basically the way I'm
going to implement this.
In Mozilla Bugzilla #18764, Tomer Cohen (tomer-gmx) wrote : | #19 |
What's going on with this bug?
In Mozilla Bugzilla #18764, 2009-bugzilla (2009-bugzilla) wrote : | #20 |
*** Bug 108329 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Mporta (mporta) wrote : | #21 |
now i see that this bug is targetted for mozilla 1.1
i really hope that it won't be postponed again.
thanks.
In Mozilla Bugzilla #18764, Stig-moz (stig-moz) wrote : | #22 |
I'm finding content on the net encoded in this format with .mht file
extensions...and I'd like to use the format myself to encapsulate saved web
pages...hmmmmmmmmm, for that matter, file->"save as" {c,sh}ould save the file
and it's images in one blob. this seems like a half-decent-enough format
(except that it mime-encodes images so they bloat)...okay, then .mht.gz...(yeah,
there's .war too [from konqueror])
In Mozilla Bugzilla #18764, Stephan-email (stephan-email) wrote : | #23 |
target milestone 1.1alpha is out of date...
Is there any progress going on?
In Mozilla Bugzilla #18764, Bzbarsky (bzbarsky) wrote : | #24 |
*** Bug 176054 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Bzbarsky (bzbarsky) wrote : | #25 |
*** Bug 177713 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Benc-meer (benc-meer) wrote : | #26 |
Is this networking of file handling?
In Mozilla Bugzilla #18764, volkris (volkris) wrote : | #27 |
Pardon me if I'm wrong, but it seems to be that this is under both networking
and filehandling.
My main want is to be able to open a single file (whether it be downloaded from
an ftp site or opened from my desktop) with all graphics, stylesheets, and html
included.
In Mozilla Bugzilla #18764, 3-14 (3-14) wrote : | #28 |
Is there a testcase available somewhere?
pi
In Mozilla Bugzilla #18764, Lapsap7+mz (lapsap7+mz) wrote : | #29 |
Sorry, I haven't (time to) read RFC2557, but I'd like to make a wish:
when MHTML is opened (in browser), it would be nice if the From, Date, etc
fields aren't displayed.
Excuse-me if this wish isn't adequate and doesn't seem to be within topic of
this bug because my bug got being marked as a dup of this.
In Mozilla Bugzilla #18764, Test2345 (test2345) wrote : | #30 |
Created an attachment (id=113008)
This Page as MS MHTML
This page saved with MS IExplorer (6)
In Mozilla Bugzilla #18764, Test2345 (test2345) wrote : | #31 |
Created an attachment (id=113016)
More Complex Testcase with Frames
After upgrading from MS Internet-Exploder to Mozilla (security reasons) I
really miss the MS-Feature of saving complete Webpages into one single File.
With a huge collection of documents on your hard drive it matters very much how
the files are organized and structured. I hope this issue will get a higher
priority. I wonder why Netscape/Mozilla did not make a progress in that
direction for years.
Frank
In Mozilla Bugzilla #18764, volkris (volkris) wrote : | #32 |
One of the main reasons I want such a thing is so that I can use Mozilla and its
composer for writing general reports.
Basically I propose that there are few examples of report styles, formats, and
uses that wouldn't be entirely handled by HTML/XML/CSS/etc. There just aren't
any particularly good front ends for writing these reports.
Anyway, I want to be able to view, print, and edit my reports on computers
without bothering with a word processor at all. I SHOULDN'T need anything other
than Mozilla, but this bug makes transmission of such documents more cumbersome.
In the end this is one of those feature requests where the potential uses are
nearly limitless in number.
In Mozilla Bugzilla #18764, Thoste (thoste) wrote : | #33 |
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
In Mozilla Bugzilla #18764, Goa-ifrance (goa-ifrance) wrote : | #34 |
As a developer I can tell you it's not that easy ! However I think Mozilla
developers could use some help so here goes a useful link :
http://
The article contains useful information about IE and its so famous (^^) save as
MHTML feature . Developers should also read the user comments.
In Mozilla Bugzilla #18764, Wasti-redl (wasti-redl) wrote : | #35 |
>somehow we must remember that we have an MHTML document if we don't want to
>rewrite its links. URIs in MHTML documents can be the same as existing URIs
>outside the MHTML document. If we rewrite the links (e.g. convert them to <cid:>
>URIs) it is very likely that we break at least some JS.
How does IE do it?
In Mozilla Bugzilla #18764, Pedro-lamarao (pedro-lamarao) wrote : | #36 |
Me, and my employer, are interested in the implementation of this feature.
If there is no one working on it, or if there is someone working on this having
trouble, I'd like to give it a try.
So, feel free to contact me with pointers about how to go about it.
In Mozilla Bugzilla #18764, Test2345 (test2345) wrote : | #37 |
I changed from IE to Mozilla just for security reasons. I'm still missing this
nice MHTML feature. There are many HTML documents with important inline
graphics, like pages with embedded math formulas as GIF or graphs.
For me it's not important that all features of a web page are preserved.
Javascript can be broken, that's not important to me as it's used mostly for
advertisements. Also I don't care much about CSS as the content is more
important to me as a correct layout. This topic is discussed now for more than 4
years. So, maybe a simple approach at the beginning would be sufficient. The
mail component is using already a similar functionality. Javacript/CSS, external
Link and Layout optimizations can be made later.
In Mozilla Bugzilla #18764, Bijumaillist (bijumaillist) wrote : | #38 |
(In reply to comment #37)
> I changed from IE to Mozilla just for security reasons. I'm still missing this
> nice MHTML feature. There are many HTML documents with important inline
> graphics, like pages with embedded math formulas as GIF or graphs.
> For me it's not important that all features of a web page are preserved.
Actually Moz… is at least capable of viewing *.mht files created by IE. I tried
following.
1. in IE. Opened a web page with graphics
2. saved it as *.mht file
3. Opened a new message in Thunderbird
4. Attached the *.mht file
5. save the message as draft
6. view the saved draft message in preview pane
7. I am able to see the complete web page with graphics and css
If Thunderbird is capable of viewing a *.mht Mozilla.org has code to show it in
the browser.
But I dont whether there is code to save it!!
Alternative, Mozilla is capable of viewing contents inside a zip file (including
pages with graphics and css). So why not make a XPCOM component to update zip,
then extension developers can use that to make a single file achieving facility.
See topic http://
In Mozilla Bugzilla #18764, Test2345 (test2345) wrote : | #39 |
When I should make a ranking about the most important improvements in Mozilla
browser, this one would be on Nr. 1.
I like mozilla, but not for the fact that it makes my document folders
absolutely chaotic with all the subfolders of page contents - really stupid.
Maybe we should convince some active developers to look at this issue and forget
about other things like making Mozilla look even more beautiful. Unfortunately
the Internet Explorer is no alternative to me because of the security problems.
Otherwise I would have changed back again, because IE is able to properly save
web pages.
In Mozilla Bugzilla #18764, Bijumaillist (bijumaillist) wrote : | #40 |
At present mozilla allow to view STUFF from a zip file.
STUFF may be a web page saved as "Web page, complete" format.
see following
jar:http://
(if your are unable to see it try
http://
or the snipped url http://
Now all we need is an option to zip the contents of "Web page, complete" format
while saving.
(PS: at present the mozilla zip services dont allow to add/update file in a zip
file)
one advatage of zip format over mhtm is we can access content using any ziptool
and it is a non XML format.
disadvantage is zip file format dont store mime-type info of contained files
to resolve this we could store an additional content list file (say content.lst)
which list file names inside the archive and its mime-type.
content.lst should also contain an entry to indicate the root html file.
content.lst should NOT be in XML format.
XML is difficult to process using shell script
In Mozilla Bugzilla #18764, volkris (volkris) wrote : | #41 |
(In reply to comment #40)
> At present mozilla allow to view STUFF from a zip file.
> STUFF may be a web page saved as "Web page, complete" format.
Of course you realize this would be an entirely different enhancement request...
A zipped file as you describe isn't rfc2557 MHTML.
In Mozilla Bugzilla #18764, Timeless-bemail (timeless-bemail) wrote : | #42 |
In Mozilla Bugzilla #18764, Bijumaillist (bijumaillist) wrote : | #43 |
(In reply to comment #41)
> A zipped file as you describe isn't rfc2557 MHTML.
I know…
But my frustration this bug/enhancement is reported on 1999-11-13 00:58 PDT
And I know *.mht can be viewed in thunderbird.
Regarding security issue, contents of the *.mht file, or of *.zip file should
run under same security as html file hosted at same website.
In Mozilla Bugzilla #18764, SteBo (stebo) wrote : | #44 |
*** Bug 241240 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Bugzilla-mozilla-org-khopis (bugzilla-mozilla-org-khopis) wrote : | #45 |
re: comment 40: zip format is discussed in bug 64286.
re: comment 43: we need a complete re-write to support mhtml in the browser.
(see comment 18, where the bug assignee, Clarence, notes this.)
biggest problem with this bug is that nobody is actively working on it,
just a lot of us actively watching it as it sits there smiling back.
In Mozilla Bugzilla #18764, Xknight (xknight) wrote : | #46 |
MAF (http://
In Mozilla Bugzilla #18764, Christian Biesinger (cbiesinger) wrote : | #47 |
actually, I'm not going to continue working on this... I stopped when I realized
I'd need a streaming base64 decoder
In Mozilla Bugzilla #18764, Test2345-online (test2345-online) wrote : | #48 |
Did you already notice that MAF can load and save MHTML ?
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.
In Mozilla Bugzilla #18764, Bijumaillist (bijumaillist) wrote : | #49 |
(In reply to comment #47)
> actually, I'm not going to continue working on this... I stopped when I realized
> I'd need a streaming base64 decoder
Please check window.atob() and window.btoa() function are useful or not
In Mozilla Bugzilla #18764, Bugzilla-accessibleinter (bugzilla-accessibleinter) wrote : | #50 |
*** Bug 268151 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Bugzilla-accessibleinter (bugzilla-accessibleinter) wrote : | #51 |
*** Bug 275302 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Mike Connor (mconnor) wrote : | #52 |
*** Bug 278968 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Juergen-jwi (juergen-jwi) wrote : | #53 |
(In reply to comment #48)
> Did you already notice that MAF can load and save MHTML ?
>
> http://
>
Unfortunately MAF does not work with 1.5 Betas anymore.
In Mozilla Bugzilla #18764, Alicaccs (alicaccs) wrote : | #54 |
(In reply to comment #53)
> (In reply to comment #48)
> > Did you already notice that MAF can load and save MHTML ?
> >
> > http://
> >
> Unfortunately MAF does not work with 1.5 Betas anymore.
It works if you override MAF's Firefox version checking. Nightly Tester Tools can help you do this. Developers of MAF still should update their package, though...
In Mozilla Bugzilla #18764, Emmapwork (emmapwork) wrote : | #55 |
Hi,
yes mhtml exporting and loading is a good thing: no need to have several files lying around with the main html page.
In Mozilla Bugzilla #18764, Darin-moz (darin-moz) wrote : | #56 |
-> nobody
In Mozilla Bugzilla #18764, Eyalroz (eyalroz) wrote : | #57 |
*** Bug 52386 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Tmptgr (tmptgr) wrote : | #58 |
(In reply to comment #48)
> 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.
>
MAF uses a custom "Save as, complete" function that puts the result and a metadata RDF file in timed folder in a ZIP file. If you want to view it in a different app, just unzip, enter the folder you want (you can add pages to an existing MAFF), and open index.html.
MAF's MHT output differs from IE though. There are some unexplained options to tweak that.
In Mozilla Bugzilla #18764, Hfwong1 (hfwong1) wrote : | #59 |
It's really a shame that mozilla do not try their best to support MHTML...
Its a reason why many people still uses IE
In Mozilla Bugzilla #18764, Tmptgr (tmptgr) wrote : | #60 |
Why is this not a duplicate of bug 40873? I think networking downloads pages just fine. Or are the missing items supposedly fixed by https:/
In Mozilla Bugzilla #18764, Bugzilla-glob (bugzilla-glob) wrote : | #61 |
(In reply to comment #60)
> Why is this not a duplicate of bug 40873?
that's about saving, this is about viewing.
In Mozilla Bugzilla #18764, Stephanie Daugherty (sdaugherty-deactivatedaccount) wrote : | #62 |
Adding myself as CC, IMHO this needs to be a high priority - the current functionality for saving pages to disk is seriously lacking, and this is something that IE has done correctly for a long time.
The votes for this bug show a strong demand for this feature, but apparently, the people most interested in having this functionality aren't in a position to implement it.
Could we please get some developer attention here, it would be nice to have this make it in to a release soon.
In Mozilla Bugzilla #18764, Dtownsend (dtownsend) wrote : | #63 |
*** Bug 392732 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Sakesaru (sakesaru) wrote : | #64 |
It's a little sad that there is an addon for Firefox that gives us this, yet the browser cannot have it by default.
IE and Firefox don't have a shared format for single-file web pages. Having support for this format would be excellent. It is the type of file a browser should be able to open.
In Mozilla Bugzilla #18764, Moz-jeka (moz-jeka) wrote : | #65 |
BTW, Opera 9 has full support for .mht files.
In Mozilla Bugzilla #18764, Dtownsend (dtownsend) wrote : | #66 |
*** Bug 407599 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, John-traynor (john-traynor) wrote : | #67 |
Sorry my current report was a duplicate. I've now scanned this history and frankly find it amazing that the 'bug' has been around over 8 years.
In Mozilla Bugzilla #18764, Peter-lairo (peter-lairo) wrote : | #68 |
Could someone please add "viewing" and "Display" to the subject, in order to avoid confusion between this bug (View/Display MHTML) and bug 40873 (Save MHTML).
Old: Full rfc2557 MHTML multipart/related support in BROWSER
New: Display/View MHTML in BROWSER (Full rfc2557)
BTW: I lost a potential convert from IE to Firefox today because he saves recipes from e.g., http://
In Mozilla Bugzilla #18764, Lapsap7+mz (lapsap7+mz) wrote : | #69 |
I don't think it's necessary to change the title since a full RFC2557 support implies view/display.
In Mozilla Bugzilla #18764, Tbertels+bugzilla (tbertels+bugzilla) wrote : | #70 |
I think what 石庭豐 means is that full RFC2557 support = view + save, so this bug bug covers bug 40873.
In Mozilla Bugzilla #18764, Lapsap7+mz (lapsap7+mz) wrote : | #71 |
Yeah, the majority of RFC2557 talks about how to parse and interpret the content (eg section 8). If that's not for display (and save), what's the use of support it? :)
peter (peter-howav) wrote : "If you are seeing this message, this means your browser or editor doesn't support Web archive files" | #72 |
Binary package hint: firefox-3.0
this location http://
displays
This document is a Web archive file. If you are seeing this message, this means your browser or editor doesn't support Web archive files. For more information on the Web archive format, go to http://
I am using ubuntu 8.04
ProblemType: Bug
Architecture: i386
Date: Sun Jun 15 10:28:40 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelMo
Package: firefox-3.0 3.0~rc1+
PackageArchitec
ProcEnviron:
PATH=/
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-18-generic i686
peter (peter-howav) wrote : | #73 |
- Dependencies.txt Edit (2.6 KiB, text/plain; charset="utf-8")
- ExtensionSummary.txt Edit (1.3 KiB, text/plain; charset="utf-8")
- profiles.ini.txt Edit (94 bytes, text/plain; charset="utf-8")
Vojtěch Trefný (vojtech.trefny) wrote : | #74 |
Thank you for reporting, but this is not real bug. I'm converting this to question.
Changed in firefox-3.0: | |
status: | New → Invalid |
Thomas Kluyver (takluyver) wrote : | #75 |
Strictly, I think this is a bug, or at least a possible wishlist item. I've linked it to Firefox's bug tracker. But since that has been around since 1999, don't expect any immediate action. I don't think many people now use MHT--even the officeupdate link it points you to is defunct.
Workaround: http://
Changed in firefox: | |
status: | Unknown → Confirmed |
John Vivirito (gnomefreak) wrote : Re: [Bug 240133] Re: "If you are seeing this message, this means your browser or editor doesn't support Web archive files" | #76 |
Bug Watch Updater wrote:
> ** Changed in: firefox
> Status: Unknown => Confirmed
>
>
For future reference if you see its a site issue as this warning implies
please report a bug using Help > Report a Broken Website because there
isnt anything we can do to work around websites.
--
Sincerely Yours,
John Vivirito
https:/
https:/
Linux User# 414246
John Vivirito (gnomefreak) wrote : | #77 |
Vojt?ch Trefný wrote:
> Thank you for reporting, but this is not real bug. I'm converting this
> to question.
>
> ** Changed in: firefox-3.0 (Ubuntu)
> Status: New => Invalid
>
> ** bug changed to question:
> https:/
>
>
Yes this is a very real bug but not a Ubuntu bug its an upstream bug due
to a broken website. the more sites that we report upstream using Help
>report a Broken Website there is a bigger chance of these sites getting
fixed. There is no text on this bug that makes me thing it is a
question. I will close question
--
Sincerely Yours,
John Vivirito
https:/
https:/
Linux User# 414246
John Vivirito (gnomefreak) wrote : Re: "If you are seeing this message, this means your browser or editor doesn't support Web archive files" | #78 |
- badget11.mht Edit (173.5 KiB, message/rfc822)
I just tried to reproduce htis with the link given and i see it as text document on the site given. the attachment is what i see when i open that page.I dont see any pictures or anything except text.
In Mozilla Bugzilla #18764, John Vivirito (gnomefreak) wrote : | #79 |
This has also been reported to Launchpad bug tracker for Ubuntu.
https:/
John Vivirito (gnomefreak) wrote : Re: "If you are seeing this message, this means your browser or editor doesn't support Web archive files" | #80 |
Movied back to bug.
John Vivirito (gnomefreak) wrote : | #81 |
Marked as confirmed and moved back to bug report.
Changed in firefox-3.0: | |
status: | Invalid → Confirmed |
In Mozilla Bugzilla #18764, Matti-mversen (matti-mversen) wrote : | #82 |
*** Bug 445761 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Dtownsend (dtownsend) wrote : | #83 |
*** Bug 448960 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Suhas-patils (suhas-patils) wrote : | #84 |
Actually, not only being able to save the page in mhtm format is helpful but even sending the page from the webserver is equally useful. This feature would drastically cut down time taken for loading multiple web requests for different resources and the overhead of creating and breaking down the connection. Considering it is such a useful and powerful feature, it is surprising that even google's chrome has not supported it.
In Mozilla Bugzilla #18764, Acelists (acelists) wrote : | #85 |
Hi, is it correct that this bug is in the 'Networking' component?
In Mozilla Bugzilla #18764, Hfwong1 (hfwong1) wrote : | #86 |
When can this bug be finally fixed?
In Mozilla Bugzilla #18764, Mogul-mozilla (mogul-mozilla) wrote : | #87 |
Those who are still running into periodic need to view .mht files (like those my HR insists on sending me when they find a resume for me on the web) may be interested to know about this add-on:
http://
I'm not sure when it came on the scene, but it's now indispensible... Seemed to work pretty well in all occasions I've had to try it so far.
In Mozilla Bugzilla #18764, Matti-mversen (matti-mversen) wrote : | #88 |
*** Bug 471270 has been marked as a duplicate of this bug. ***
John Vivirito (gnomefreak) wrote : Re: "If you are seeing this message, this means your browser or editor doesn't support Web archive files" | #89 |
Are you still able to reproduce this bug?
Micah Gersten (micahg) wrote : Re: MHTML Format - Web Archive Files - not supported in Firefox | #90 |
@John Vivirito
This hasn't been fixed as of FF 3.5b5pre
description: | updated |
summary: |
- "If you are seeing this message, this means your browser or editor - doesn't support Web archive files" + MHTML Format - Web Archive Files - not supported in Firefox |
Changed in firefox-3.0 (Ubuntu): | |
importance: | Undecided → Low |
status: | Confirmed → Triaged |
In Mozilla Bugzilla #18764, Mardeg (mardeg) wrote : | #91 |
*** Bug 509285 has been marked as a duplicate of this bug. ***
Micah Gersten (micahg) wrote : Re: MHTML Format - Web Archive Files - not supported in Firefox | #92 |
Firefox 3.0 is only receiving Security Updates and major bug fixes at this point.
Changed in firefox-3.0 (Ubuntu): | |
importance: | Low → Wishlist |
status: | Triaged → Won't Fix |
Micah Gersten (micahg) wrote : | #93 |
Moving tracking to Firefox 3.5
Changed in firefox-3.5 (Ubuntu): | |
importance: | Undecided → Wishlist |
status: | New → Triaged |
In Mozilla Bugzilla #18764, Lapsap7+mz (lapsap7+mz) wrote : | #94 |
Just tried the add-on. I have to give it a "thumb up"!
... Although there's pitfall to avoid: conflict with "IE tab" and have to disable a special URL. It's written in the webpage... at about the very last part of it (not easy to spot it if one has no idea what to look for)
In Mozilla Bugzilla #18764, Kevin Brosnan (kbrosnan) wrote : | #95 |
*** Bug 538108 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Davian818 (davian818) wrote : | #96 |
I need that feature.
In Mozilla Bugzilla #18764, Bugzilla2010 (bugzilla2010) wrote : | #97 |
I think this bug after 11 years should be WONTFIX, given the addon mentioned in comment 78 works great, and this is clearly not on the developers' priority list. I voted for it but I'm well aware that this is not a feature wanted or needed by the vast majority of users. Parity with IE is not always a good enough reason to spend time developing a feature. Especially when there are addons capable of doing the job.
In Mozilla Bugzilla #18764, Bugzilla2007 (bugzilla2007) wrote : | #98 |
(in reply to comment 84)
I doubt very much that a bug with as many as 165 votes, continuous requests for a period of 11 years so far and with recent duplicates still coming in is a likely candidate for wontfix. Maybe fix would be better.
Addons can't replace vital core functionality. Many users will never bother installing addons, but they still need and expect the functionality.
Michael, where's your data to show this isn't needed by many users?
Finally, please consider that the lack of "parity with IE" in this case means that users who already use Firefox might be tempted to switch back to IE both for viewing and saving all-in-one rfc2557 MHTML files. I'll take it a step further and state that both MHTML and .maff format should be natively supported by the browser. Only after many years of using FF did I discover .maff add-on, and I'm not very shy of addons. Current default of saving html pages as a "file + loads of files in subfolder" set is very impractical and resource-wasting. Let alone all the problems you can get when copying over-long file paths resulting from saved html files. Mozilla should really do better.
In Mozilla Bugzilla #18764, Bugzilla2007 (bugzilla2007) wrote : | #99 |
(In repetition of comment #76)
> Is it correct that this bug is in the 'Networking' component?
In Mozilla Bugzilla #18764, Barebonesphoto (barebonesphoto) wrote : | #100 |
MHTML is not an approved standard. It is a Microsoft idea that other browser developers have followed. Whether Firefox follows the trend or not is a choice. If they don't, it is not a bug. We already have Zip to archive web pages and related objects. Using an add-on to do the archive from within Firefox is a convenience not a bug fix.
In Mozilla Bugzilla #18764, Peter-lairo (peter-lairo) wrote : | #101 |
(In reply to comment #87)
> it is not a bug.
> is a convenience not a bug fix.
That is why this "bug" is an "enhancement" (with 164 votes).
In Mozilla Bugzilla #18764, Laughing-john (laughing-john) wrote : | #102 |
165 Votes!
I don't really care who invented it or whether it is a bug or an enhancement. All
I know is it's something I would find very very useful and I would really like to see it integrated into FF.
The reason I don't 'need' it is because I just use Internet Explorer every time I want to save a single page as MHTML, but I'd rather not have to do that! In an ideal world all browsers would support this as a standard (drops dead laughing).
In Mozilla Bugzilla #18764, Relgoshan (relgoshan) wrote : | #103 |
I use this feature frequently in Opera, because my PCs all have different OSes.
In Mozilla Bugzilla #18764, Tomer Cohen (tomer-gmx) wrote : | #104 |
I've recently read on Planet Mozilla that Fennec will imply a "Save as PDF" feature for the next release, in order to make saving websites easy on mobile platforms. Since Firefox and Fennec share some amount of code, it might be possible to re-prioritize this issue in order to make it a better alternative for "Save as PDF", as MHTML is more open format than PDF.
http://
In Mozilla Bugzilla #18764, Relgoshan (relgoshan) wrote : | #105 |
Huh. Looks like Fennec won't be much of a threat for now, then. Perhaps if it saved as PDF and then emailed it, we may have a killer feature. His screenshot also exposes the lingering "unknown size" bug.
So Fennec will be able to save files as a type it can't even read? Sounds counter-intuitive. MHT is not perfect, but wider adoption will force the standard to make some improvements of its own.
Changed in firefox: | |
importance: | Unknown → Wishlist |
In Mozilla Bugzilla #18764, Mar-castelluccio (mar-castelluccio) wrote : | #106 |
The UnMHT extension does this work, can we integrate it into Firefox?
In Mozilla Bugzilla #18764, Moz-jeka (moz-jeka) wrote : | #107 |
Provide a patch, write tests, ask for review, address review comments, let it land, done.
In Mozilla Bugzilla #18764, Arho-huttunen (arho-huttunen) wrote : | #108 |
Before someone wastes their time I actually tried to implement this back in 2008 or 2009 and ran into unexpected problems. This task isn't as trivial as it at first seems. Let's just say that you can't just take UnMHT or Thunderbird and make it work in Firefox.
In Mozilla Bugzilla #18764, Andre Klapper (a9016009) wrote : | #109 |
*** Bug 603476 has been marked as a duplicate of this bug. ***
summary: |
- MHTML Format - Web Archive Files - not supported in Firefox + MHTML Format - Web Archive Files - Standard not supported in Firefox |
In Mozilla Bugzilla #18764, Tomer-moz-bugs (tomer-moz-bugs) wrote : | #110 |
I've found that Chromium does have MHTML support[1], although it is still marked as experimental and require manual toggling in its configuration page. Supporting MHTML would allow us to easily make desktop HTML5 portable applications, and I think it would be more useful to our users and more reflecting our mission to support the web, than, for example, building our own built in PDF viewer.
[1] https:/
In Mozilla Bugzilla #18764, Sylvhem (sylvhem) wrote : | #111 |
I think this is a very useful feature. When you save a webpage with a view to read it outline or later, it is more convenient to have a single file.
(In reply to Lance Baker from comment #87)
> MHTML is not an approved standard. It is a Microsoft idea that other browser
> developers have followed.
Among the authors of the RFC2557, only one works for Microsoft. Moreover, it is not like if MHTML is a closed file format: the specification is public and part of IETF's work.
In Mozilla Bugzilla #18764, Julian-reschke (julian-reschke) wrote : | #112 |
(In reply to Lance Baker from comment #87)
> MHTML is not an approved standard. It is a Microsoft idea that other browser
> developers have followed. Whether Firefox follows the trend or not is a
> choice. If they don't, it is not a bug. We already have Zip to archive web
> pages and related objects. Using an add-on to do the archive from within
> Firefox is a convenience not a bug fix.
It's a specification approved as "proposed standard" by the IETF. Just like many other things the internet runs on.
In Mozilla Bugzilla #18764, Kevin Brosnan (kbrosnan) wrote : | #113 |
*** Bug 1028603 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, Andrea Faulds (ajf.me) wrote : | #114 |
It's a shame that after 18 years, Mozilla still has no support for MIME HTML. If I knew C++ and the codebase, I'd write a patch, but alas.
I hope this comment might remind someone this exists and spur them into action.
In Mozilla Bugzilla #18764, Lapsap7+mz (lapsap7+mz) wrote : | #115 |
(In reply to ajf from comment #101)
> It's a shame that after 18 years, Mozilla still has no support for MIME
> HTML. If I knew C++ and the codebase, I'd write a patch, but alas.
There is actually an alternative solution and we don't need to know C++. It was suggested in comment #78 and confirmed in comment #93: use the add-on called UnMHT (https:/
I've seen comment #95 saying that it does not work for him. Maybe the commentator didn't use the right method? We cannot put the xpi file like that inside "extension" folder. In all cases, the file name has to be changed. In some cases, it's also necessary to unpack the file. For UnMHT, filename change is enough. Here are the steps for FF 40:
1. Download unmht-8.
2. Change the name to {f759ca51-
3. Put it into "extension" folder. There are two extension folders in Windows:
a. System-wide:
Put it in "C:\Program Files (x86)\Mozilla Firefox\
b. User-wide:
Put it in C:\Users\
4. In either case, it's still necessary to explicitly enable the add-on.
In Mozilla Bugzilla #18764, Eyalroz (eyalroz) wrote : | #116 |
(In reply to 石庭豐 (Seak, Teng-Fong) from comment #102)
Teng-Fong, I believe you're mistaken. The core issue with MIME support is that it's based on code which is essentially a custom object system implemented in C, with polymorphic construction by class name, and other strangeness. It is very tricky to work with, and what's _really_ necessary is getting rid of it in favor of a proper C++'ish MIME library. Problem is, it's like a house of cards which collapses on top of you when you do that. Last decade I had tried to initiate this kind of a rewrite, but it didn't work out. See also Arho's comment #95.
Anyway, something like UnMHT are not really a solution, it's a workaround; and it would not be reasonable to integrate it. It would be yet another layer over the problematic core.
Changed in firefox (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
no longer affects: | firefox-3.0 (Ubuntu) |
no longer affects: | firefox-3.5 (Ubuntu) |
In Mozilla Bugzilla #18764, Mardeg-5 (mardeg-5) wrote : | #118 |
Patrick, could you please provide a link to the source of, or just state/quote the reasoning behind, the decision to resolve this as WONTFIX?
In Mozilla Bugzilla #18764, Patrick McManus (mcmanus-ducksong) wrote : | #119 |
This isn't on anyone's roadmap and nobody has provided a patch for it in 15 years - so its just clogging up bugzilla. That doesn't mean it isn't a good idea - it just means nobody is planning on working on it. If someone works on it then this should be opened as a new issue.
Changed in firefox: | |
status: | Confirmed → Won't Fix |
In Mozilla Bugzilla #18764, Andrea Faulds (ajf.me) wrote : | #120 |
But marking it as WONTFIX means that there's been a conscious decision made not to implement it, right? Here it's just a case that nobody's done it. It might be done someday.
In Mozilla Bugzilla #18764, Ondra Žižka (zizka) wrote : | #121 |
How will someone looking for things to work on find this request?
In Mozilla Bugzilla #18764, longsonr (longsonr) wrote : | #122 |
*** Bug 1336793 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #18764, danny0838 (danny0838) wrote : | #123 |
RFC 2557 MHTML is a standarized format for web page archive that deemed to be directly readable for web browsers and is already supported by many browsers such as IE and Chrome.
However, Firefox does not directly support it. Although we currently have addons like MAF (https:/
Therefore, we need a support for RFC 2557 MHTML support, at least a directly reading, and saving at best. This could either be:
1. Directly support for MHTML reading and writing
2. Add enough API to allow an addon like MAF or UnMHT in WebExtension
In Mozilla Bugzilla #18764, Stevenwdv (stevenwdv) wrote : | #124 |
Now that UmMHT etc. do not work anymore the only add-on supporting mht is Save Page WE, but it only has support for saving pages as mht, not for opening them.
Changed in firefox: | |
importance: | Wishlist → Medium |
Copied the following comment from bug 17309 (cc-ing contributor):
>------ Additional Comments From <email address hidden> 11/13/99 07:03 ------
>Authors could add the proprietary "important" keyword to the list of keywords
>in the rel attribute of the link element, e.g., rel="important stylesheet" (or
>rel="stylesheet important") to do what you want without resorting to RFC2557.
Yes, they could, but they would have no guarantee that Mozilla or any other
browser would either interpret that they way they want or implement the
behaviour they want in response, nor that a future version would not do
something slightly or markedly different.
Providing an rfc2557 MHTML mechanism would take care of the extreme case,
leaving room for a reasonable policy for "important stylesheet" that would
not necessarily mean "absolutely required" from this point forward.
Having said that, I absolutely would not advocate MHTML in the browser as the
*only* mechanism provided to authors to indicate how important or necessary
a stylesheet is, lest this feature get thought of by anyone as the only way
to go. I'd go so far as to say don't add the feature if nothing else is
provided as a fix for bug 17309.