Closed Bug 678 Opened 22 years ago Closed 19 years ago
text/html and text/plain OBJECTs don't work
Attempts to display embedded HTML and text files, using every combination of DATA, TYPE and (WIDTH and HEIGHT) parameters in the OBJECT tag
687 bytes, text/html
4.51 KB, patch
|Details | Diff | Splinter Review|
5.10 KB, patch
|Details | Diff | Splinter Review|
8.39 KB, patch
|Details | Diff | Splinter Review|
5.38 KB, text/html
615 bytes, text/plain
This page contains several Object tag tests. I couldn't get any of them to work in Raptor. I'm using the release build.
Assignee: michaelp → amusil
Status: ASSIGNED → NEW
Component: Unknown → Plug-ins
Changing platform to ALL since this is most likely an XP problem
Changing platform to ALL since this is most likely an XP problem
*** Bug 1155 has been marked as a duplicate of this bug. ***
*** Bug 1156 has been marked as a duplicate of this bug. ***
*** Bug 1158 has been marked as a duplicate of this bug. ***
Andrei - can you meet with Kipp and/or Troy sometime in the next few days to go over object tag issues?
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
assigning Eli as QA contact
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This can be considered fixed as to original incorrect behaviour
oh happy day! the object element is working, going through Antti's test suite and have found other issues, but this particular bug is fixed.
I tried the "HTML and plain text documents" tests at the attached site and they do not work on Windows M8
Clearing Fixed resolution due to Reopen.
Moving from M4 to M9 since M4 way gone.
Michael, did they work in previous spins?
I tried it in M4 or so and it didn't work then either.
Summary: Object tag does not work → HTML objects are not displayed with object tag
See http://www.w3.org/TR/html40/struct/objects.html#h-13.5 for what HTML has to say on this.
I went through a few of the tests -- specifically some of the image tests and they render correctly. However, the HTML and plain text tests do not render the file specificed in the data attribute. I checked to ensure that the file specified was present in the current directory, and they are both there. I used the 1999090108 build on win98 -- I do not have access to other platforms at this time.
Lowering priority and moving
Hi, Beppe --- This looks object related; would that be petersen? (it's not me) thanks!
Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over to him.
See also these test cases: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-unknown.html http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-broken.html http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-noattr.html They demonstrate bug 797, bug 15019 and bug 22047 respectively. Shrir: I'm the QA contact for HTML 'alt text' bugs, if you think that the object elements' alternate content classifies as 'alt text' then feel free to put me in as QA contact for this bug.
I'd like to suggest a priority boost for this bug, since it's required for compliance with Sec 13.5 of the HTML spec.
*** Bug 36312 has been marked as a duplicate of this bug. ***
PLEASE raise the priority of this bug! Client-side HTML inclusions, using the < OBJECT> tag, "before:" or "after:" psuedoclasses of CSS2, or the still-in- development XLink specification are the singular features that will drive the post-HTML-3.2 web forward fastest. The demand is evident and unavoidable: anywhere you see HTML documents being embedded within each other on a server using a script (for instance, any portal page, "slashboxes" down the side of http://slashdot.org/, the XMLhack summaries on http://www.xml.com/, etc.) could be done more elegantly and with less server overhead and more securely (thanks to being able to eliminate added complexity of server-side cgi's or dynamic scripts) using client-side includes like this one. This is our chance, mozilla: if we can show That Other Browser Maker (TM) the benefits of an object-oriented, interconnected web as it was originally intended to be, we can improve the speed and utility of the web exponentially. Let's make it happen, please! Oh, by the way, it's also been part of the HTML specification since 1997. We should allow our collective sense of pride, as browser implementers, to be wounded that we've allowed the web to exist THIS LONG with such blatant ignorance of the standards. Shame on us.
I agree that this is important - adding 'nsbeta3' keyword because it's probably too late for nsbeta2.
Hmm. When I think of it, this bug seems to have been opened for general lack of OBJECT element support in HTML. The summary is a bit misleading - it means "OBJECT elements in HTML", not "text/html OBJECT elements in HTML". This is actually fixed now, since the OBJECT element itself and the most important attributes are working correctly. Does everybody agree that I should close this bug and open a new one called "text/plain and text/html OBJECTs don't work"?
OS: Windows NT → All
Is there a need to close this bug and open a new one? I don't see one. (People have connections to this bug.) But retitling this one would be fine.
Right, so I'm retitling this one - we can always open a new bug if the OBJECT element itself stops working. Also changed the URL to some more specific test cases. This probably isn't about plug-ins any more since no plug-in is needed to display HTML or plain text. Changing Component to HTML Element, although it could be HTMLFrames just as well? Also adding 'html4' and '4xp' keywords (the latter because IE4/5 has some support for this feature).
Status Whiteboard: firstname.lastname@example.org Keywords: makingtest This is my first bug, so I can't edit the SW or Keywords fields yet, hence the above. James
Status: REOPENED → ASSIGNED
Er, we already had a valid test case for this one - see the URL field. I'd also like to point out that the HTML/plaintext OBJECT isn't necessarily 300*200 pixels big if width & height aren't specified, which is what James' test case implies. I've already done the maximum number of Bugathon bugs anyway, so I guess the credit for this goes to James. Adding 'testcase' keyword and email@example.com to Status Whiteboard. PS. Welcome, Jamie! :-)
FYI: In addition to IE, this is now supported by Opera, too (starting from v4.0).
av, please provide any new information on this bug so we can evaluate it as a candidate for beta3- Thanks.
Whiteboard: firstname.lastname@example.org → email@example.com [nsbeta3-]
Target Milestone: M17 → Future
Braden: yes, that's true - I'm still a bit confused about the exact meaning of '4xp'. (I might as well use this opportunity to draw attention to bug 53954.)
Suggested release note: "HTML and plain text documents embedded with the OBJECT element aren't supported in this release. Workaround: use the IFRAME element instead."
Whiteboard: firstname.lastname@example.org [nsbeta3-] → email@example.com [nsbeta3-] relnote-devel
Would like to add that XML files are not working with the object tag to load files into a HTML documentor can you point to an address where it does? But it does work to load a SVG file which is also XML(?).
As suggested above, I'm using IFRAME as workaround for the broken OBJECT element to include an external text/html source in a table cell. Platform: Sun-Solaris5.7, Mozilla M18 However, I want the embedded html to fill the available space in the cell, or even drive it larger as necessary (just as if the cell had been filled directly inline). However IFRAMEs don't auto-resize. I can set the IFRAME width=100% which makes it fill the cell horizontally, but for height it seems to require an integer, which invariably results in clipping or wasted space. Any suggested solutions to this problem? Also, what is the new target milestone for the fix to the OBJECT problem? The "View Bug Activity" list indicates the latest target milestone to be M16. I'm using M18 and still have the problem.
> I can set the IFRAME width=100% which makes it fill the cell horizontally, > but for height it seems to require an integer, which invariably results in > clipping or wasted space. If this is true, please file another bug. Percentages should be allowed for both width and height in both IFRAME and OBJECT.
Buster, Would a possible fix for this be to construct a new document inside just like we do with IFRAMES in the FrameConstructor instead of an nsObjectFrame if the mime-type is text/html or text/plain? That's probably just a hack and I don't know how to later deal with modifying the OBJECT tag through the DOM in this case.
Adding Marc. Is this the oldest bug?
Whiteboard: firstname.lastname@example.org [nsbeta3-] relnote-devel → email@example.com relnote-devel
No there are seven open bugs older than this one starting with bug 350.
The IFRAME element is deprecated in XHTML 1.0 strict. So the only way to embed an html document is <object> ... Correct this bug FAST !
Stealing away..... I just went to take a look at nsFrameFrame.cpp, the frame class for IFRAMEs and it doesn't look like simply creating this type of frame instead of an object one and leaving the content the same will work as is done with the object tag and images. Looks like there is too much reliance on the content. So, I see two ways of fixing this: 1) [Easy Way] Is to simply change the content node if OBJECT type=text/html to that of an IFRAME and let nsFrameFrame.cpp do all the work. This seems like a bit of a hack and I'm not quite sure how the DOM would like us replacing the author's content with that of deprecated content? I'm not even quite sure the author and spec would even be effected or notice. Any core layout junkies know? 2) It doesn't look like there is a whole lot of code needed to create a webshell and docshell subdocuments in nsFrameFrame.cpp. Hooking up the views and view managers looks most complicated. A few things already stand out in my mind as needing special attention such as printing and events. Since nsObjectFrame.cpp is already huge, at least one more class would need to be created. Seems like a lot of work. 3) [Just thought of this one] Does the spec say anything is wrong with actually creating a plugin to handle types of text/html? Instead of creating another frame class, could one create an XPCOM plugin to handle XHTML mime types? How would this interfear with the DOM? I guess XPConnect could be used for scripting. Question, what ever happened to using DIVs to do this? Do they still accept the SRC= attribute? I bet that's deprecated in XHTML 1.0 strict too. So the only way to embed an html document is with <object>.
Assignee: av → peterlubczynski
Status: ASSIGNED → NEW
(3) strikes me as exactly the way this ought to work. (Indeed, that's how I'd assumed it would be implemented all along. Shows what I know....) I don't know what you're referring to with DIVs; they haven't had a SRC attribute in any version of standard HTML (it's not even there to be deprecated).
What about the variant of (1) that would use anonymous content as a child of the OBJECT rather than replacing the object element in the DOM? (I'd rather see the anonymous content creation with XBL, although it would probably be easier to just do another implementation of nsIAnonymousContentCreator...)
Anonymous content creation with XBL sounds like it may be the way to go but I'm not too familiar with XBL or the nsIAnonymousContentCreator. Are there some good examples in code you can point me to? cc:ing Hyatt Looking again at object frame, for images at least, it creates an image frame that's a child of the empty object. I guess I could make an nsFrameFrame the child. Either way a new webshell will need to be created. cc:ing Adam Lock for his input. Doing this in layout (#1) would probably be a more tightly coupled implementation whereas using plugins would be more "plug-able". Another variation of #3 is to create a 4.x plugin wrapper and use that in Mozilla and other bowsers. It probably would be quite simple as we already do that with ActiveX for with the MozControl. Just think, Nav 4.x and IE could use Gecko as it's rendering engine on both Mac and Windows.
Status: NEW → ASSIGNED
*** Bug 81557 has been marked as a duplicate of this bug. ***
I was just wondering (see bug 77539) whether an OBJECT embedding a text/html document should look like an IFRAME. Perhaps it shouldn't, except that it should have 'overflow: auto' by default so that if height and width are given then it will get scrollbars if the contents are larger? Without height and width, should it just embed one document in another? Also see http://www.w3.org/TR/html4/struct/objects.html#embedded-documents
"Just think, Nav 4.x and IE could use Gecko as it's rendering engine on both Mac and Windows." Oh boy, I'm getting wet dreams already. Instead of making NEW pages compatible with OLD browsers one could make OLD browsers compatible with NEW pages!! Beeing able to make a feature rich XHTML/CSS2 webpage and not having to worry about NS4.x and IE **** all over it sounds too good to be true. Is this doable ? It could even be an excellent way to "advertize"/introduce NS6.x to Windows IE users if gecko could seamlessly integrate with IE and "take over" the rendering after showing a splash screen or something.
We should be able to support: text/plain (plaintext) text/xml, application/xml (xml) text/html (html) application/vnd.mozilla.xul+xml (XUL) application/xhtml+xml (XHTML) text/rtf (rtf) [our support is a little crufty right now, but why not?] inside objects. Can anyone think of others?
..attaching patch that makes this WORK!!! We already handled images nativly in the OBJECT tag. This patch extends on the that framework by creating a new nsHTMLFrameOuterFrame. It's not a perfect solution, but at least this does something to get our XHTML correct. This bug has 31 votes, eek! I'm seeking reviews. Since we are entering the world of IFRAMEs, cc:ing mstoltz for security concerns.
Target Milestone: Future → mozilla0.9.4
Why do we need IsSupportedDocument? Isn't the correct thing just to use the category manager (see nsContentDLF.cpp), rather than adding yet another place where new document types have to be added? If theres no type argument, then we should try the mime service for extention matching. Doing extention matching is evil, but if we're going to do it, it should be done right :) Can we use this for <embed>, as well? (if a plugin isn't installed and we can deal with the mimetype internally)
I haven't looked at the patch, but the type argument should only be used to discern if it's not appropriate to download the data (that is, if it's a completely unsupported data type). If the type argument is absent, the download should be initiated. If the server at that point does not tell the client the content type of the file, then and only then is it appropriate to use filename extension or content-based guessing about the content type.
The patch does essentially mimic what we already do for images. Great effort, Peter! My concern is: when it was image only, we used to merely check for existance of a child frame to determine that we deal with an image. Now we should probably introduce a flag, some sort of enumeration type if we need to distinguish between images and different types of documents. Just a thought, I don't know yet if we really need it. Bradley Baetz wrote: >Can we use this for <embed>, as well? (if a plugin isn't installed and we can >deal with the mimetype internally) <embed> results in the same code path, so it should just work I think. Hmm... interesting point. Never tried <embed src="test.jpg">
I glanced through nsObjectFrame.cpp and it appears the only important place we check for a child is in Reflow() where we are unconditonally calling HandleImage() to do a special reflow if there are any children. Right now, I see nothing in the code for HandleImage() that would prevent it for working with documents as well. Looks pretty generic. Perhaps I'll just change the name or am I missing something? Is there another place I'm missing where we handle OBJECT-tag images special? nsContentDLF.cpp seems to be for content-viewer creation and doesn't seem to be what I need. For the IsSupported[Image|Document] call, what I really need is a service that I can pass a MIME-type and it returns a value indicating this is something we can render internally. You are right about comparing the file extensions. I found nsIMIMEService::GetTypeFromURI(nsIURI) may work better in both documents and images as (should) return a mime-type for a given URL based on extension parsing. I would also like to use nsIMIMEInfo::GetPreferredAction(action) but either I didn't use it correctly or it was incorrectly returning saveToDisk instead of handleInternally. Is there another way to do this? Images using the OBJECT tag do not check the content-type in the header at all and neither will docuemnts for now. I looked into changing this, as per spec, and it ain't easy due to the current way Reflow() works to instatiate a plugin. This last check for mime-type happens deep inside plugin streaming code and it only calls back to the plugin host, which after all, assumes it's going to be a plugin. For that to work for images and documents, we'd have to have some callback to the ObjectFrame, possibly through an nsPluginInstanceOwner, and also destroy any plugin data structures created at that point. Becase that effects both this bug and OBJECT-tag images, perhaps we should open another bug on this specific issue.
"For the IsSupported[Image|Document] call, what I really need is a service that I can pass a MIME-type and it returns a value indicating this is something we can render internally." http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDSURIContentListener.cpp#162 should do what you want. This is a public method on nsIURIContentListener, and parentURIContentListener is an attribute on the docshell. CanHandleContent should be OK if you check plugins first - I don't know if IsPreferred will respond to things which have external helper apps registered. The value from the category manager service is just the contract id for the viewer, and I don't think anything uses that directly (see http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#3884). nsIMIMEInfo::GetPreferredAction was probably returning "saveToDisk" because I think we don't use that for checking for handling stuff internally - we use the categorymanager instead. I'm not 100% sure about that though.
fwiw, data:text/html,<embed src=about:logo> crashed my nc4 for various reasons, #1 was the real jukebox plugin, later i crashed w/ data:text/html,<html><embed src=about:logo></embed></html> in general netscape4 land.
In this patch I don't see you deleted old image specific stuff. Shouldn't we do that?
Peter: Definitely agreed re. opening another bug. Since you seem to have a good handle on the problem with respect to the current code, could you do this (and CC me)? Note that this is an HTTP conformance issue. The TYPE attribute on OBJECT is *just a hint* the the browser can use to determine whether or not it should try to download the data. It is not a required attribute. And if the media type sent by the server happens to differ from that in the TYPE attribute, the client *must* honor the type sent by the server. It sounds like Mozilla may need substantial fixing in this regard.
My last comment is not relevant. I like the patch so far. r=av
Do we really want to make OBJECT elements linking to document formats work just like IFRAMEs, or do we want to come up with a better solution (see my 2001-05-22 comments)? Whatever we do here is likely to be adopted by other browsers and become the standard, and if we make this work just like IFRAME then we'll just have another redundant feature of HTML rather than something new and useful.
I would have to agree -- I always envisioned text/html objects to embed much like using ssi, or even when you pulled in content using the src attribute of the layer element in 4.x...
FWIW, I don't see this as working as similar to ssi include. An included html document will be just that-an html document, not a document fragment, and can't readily be shoved into the content tree of the current document. Furthermore, IE 5.5 already does this as an IFRAME-like thing; I'm not sure quite what we should do differently in terms of display, although obviously we should make sure that context menus, URI resolution, etc., work correctly.
External XML entities provide functionality akin to SSI's. Of course, I don't seemt to be able to get them to work in 0.9.3...I thought they worked at one point.
Should html/xml in <embed> be subject to the stylesheets in the parent document? SVG (which is the only spec I know of that defaines what happens when a documend it embedded in another) says no, and I don't think it makes sense to do so.
bbaetz: Not directly; but the OBJECT's background should show through if the embedded document's background is transparent.
bbaetz: no, styles on the parent document should not apply to embedded documents. The parent/embedded document boundary should be considered as a brick wall as far as style information is concerned, with the exception of the matter Braden mentions, which is if the embedded document's body is styled "background-color: transparent" then the parent's background should show through behind the embedded document. This is not how Mozilla's only embedding mechanism, IFRAME, presently works. See bug 50263.
(Of course, I should point out that the notion of background transparency isn't really an "exception" to my brick-wall analogy; in truth, background transparency simply means that the embedded document will draw no background behind the embedded document's content. Thus the brick wall stays intact.)
Exactly, but ssi's don't work that way (they're, well, included). Which is whjy I asked. I think that borderles iframes are probably the way to go. If its not an applet, we could try to load it normally as an iframe, and let the standard content-type handlers deal with it.
Whoops, wrong bug number for that IFRAME transparency issue. It's really bug 50623.
*** Bug 95063 has been marked as a duplicate of this bug. ***
..addressing some of dbaron's issues: 1) I think 'overflow: auto' is already set as I get scrollbars automatically 2) Could not find anything which this implementation would violate at: http://www.w3.org/TR/html4/struct/objects.html#embedded-documents 3) With no height and width specified, with an OBJECT tag, we should not display anything, not even alternate content. This is what IE 5.5 does. We do the wrong thing here anyway though. I'll file a new bug. 4) I also found some other bugs in terms of the spec in our implementation of OBJECT tag in general. I will file new bugs. 5) It at least gets _something_ working to bring us to spec and it's similar to the way we do images with the OBJECT tag.
I disagree on point 3. IE is wrong about this. HEIGHT and WIDTH are optional attributes; they are presentational hints. They should not be required to display something. Note 13.7.1 in the HTML 4.01 spec: "When specified, the width and height attributes tell user agents to override the natural image or object size in favor of these values." The "natural size" of an image or object is rarely zero. <img src="image.png" alt="Alt text"> should be presented the same way as <object data="image.png">Alt text</object>
What is the natural size of a flash animation, or a quick-time movie, or a real video stream? Can we determine those like we can the intrinsic size of an image?
But what is the "natural size" of a plugin or document? There is nothing in the plugin API to ask a plugin what its desired size is. The spec is unclear about a default size when one can not be determined. We do default to constants for the EMBED tag. Using an IFRAME tag we seem to default to the same size as IE. I think we should do similar for OBJECT.
I think we do this. Just because <embed> tag goes through the <object> code path.
Certainly OBJECT's, like any other HTML element, should default to CSS2 width and height values of auto. There was also some discussion of this problem in bug 90753 in regards to Acrobat PDF's. It seems we may need to revise the plug-in specification to facilitate communication of the intrinsic dimensions of the embedded data back to layout. As we can see in [http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsObjectFrame.cpp#627], arbitrary dimensions of 240px by 200px are assigned when an object's intrinsic dimensions cannot be determined, such as when a plug-in is involved. Try the testcase associated with that bug; you'll see the PDF assumes those dimensions. Try assigning the style, "width: 500px" to the OBJECT, and you'd expect it to then become 500px by 200px, but you'll be surprised to see both height and width become 500px.
That would be a notable deficiency of the plug-in API. Picking an arbitrary size (other than zero) is an acceptable workaround, but there really needs to be a way to ask the plugin instance what size it "wants". For vector formats, I think it's probably just as well that the plugin instance can't suggest a size to the host document. But for raster formats--notably movies--this is a real problem.
fix NULL --> nsnull, rv == NS_OK --> NS_SUCCEEDED, then sr=attinasi This solution is fine, but it will not support dynamic changes to the data= attribute (i.e. the IFrame will not be updated to the new URL) - but, we don't really support that now anyway except when it is for an image ;) Open anohter bug on that if you like...
Some time ago we even started a project to implement dynamic plugin sizing. See http://warp.mcom.com/core/plugins/projects/ and even have some leftovers in the current code. The idea was not to ask a plugin for the desired size but rather to respond to the plugin's request for the size it wants. The plan was to use NPN_SetValue call and we even have a defined variable specifically for this purporse.
I filed bug 8740 on the dynamic sizing issue two years ago. See my comments there (1999-06-23 and 2000-06-27) about why it's so important. The bug was finally resolved by setting the default size larger (240*200 px). This is what Andrei commented on that bug 2000-07-27: > plugin manufacturers can now change the plugin window size dynamically via > nsIPluginInstancePeer interface, so ideally, as I see it, the plugin itself > can determine the image size at the moment the stream starts to come to the > plugin and adjust its size accordingly. ...which made me think we already support dynamic sizing, it's just the then-current plugins that don't. But this discussion should really continue in a new bug. This bug is specifically about supporting text/html and text/plain OBJECTs (and possibly other native formats).
+ char * contentType; <------------------------------- leaked in the patch + rv = mimeService->GetTypeFromURI(uri, &contentType); + if (NS_FAILED(rv)) return; +
Marc's suggestions checked in. Leak-fix also checked in. Marking bug fixed. New bugs opened: bug 95548 OBJECT tag's type can't be changed later (like through the DOM) bug 95549 OBJECT tag: Content-type header should take precedence
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 19 years ago
Resolution: --- → FIXED
A question, should these new bugs be listed on the Bug 7954 ([META] outstanding issues for full HTML 4.01 support), or are these "small enough" not to be relevant on that list ? (actually the first would belong to the DOM I guess, but what about the second)
Marking verified as per above developet comments.
Status: RESOLVED → VERIFIED
I also have found a problem: see bug 96976 about OBJECT (and IFRAME) alternate content not being displayed when appropriate.
Is there a bug about the fact that % height and width attributes don't work on the object element?
Whiteboard: firstname.lastname@example.org relnote-devel → email@example.com relnote-devel (py8ieh: % height and width on object)
I don't know, but I bumped into this with iframes just the other day so it's not just objects. Then again, neighter IE 6.0beta or Opera 5.12 got iframes right either, so I just dropped the whole idea and made a normal frame. =( Iframes however is on the way out of the specs and cosidering no other browser gets it right also it's not a major issue. Fixing it for objects though seems highly relevant. /Stefan Huszics
Object text/html vanishes after clicking it or scrollbar An object of type text/html with style="position: fixed" is rendered correctly (finally, congratulations!!! :-), but as soon as you click the scrollbar of the containing document or into the object (link, scrollbar or anywhere else), it vanishes; the border (coloured for testing purposes) remains. See <http://pc00ep5.physik.uni-augsburg.de/test.html>. It would be so useful for navigation to have a text/html object with position: fixed, because you only have to maintain one navigation document for the whole site and with position: fixed it can replace frames, that are not in the strict DTDs, so please fix it!
Jens-Erik, that problem should be reported as a new bug, as this bug is rightfully fixed and thus closed.
O.k., I've submitted this above mentioned issue as bug #98166.
SPAM. HTML Element component is deprecated, changing to Layout component. See bug 88132 for details.
Come on Bugzilla, you can do it...
Component: HTML Element → Layout
Attachment #11035 - Attachment mime type: application/octet-stream → text/html
*** Bug 115309 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.