Closed Bug 678 Opened 26 years ago Closed 23 years ago

text/html and text/plain OBJECTs don't work


(Core :: Layout, defect, P3)






(Reporter: angus, Assigned: peterlubczynski-bugs)




(Keywords: html4, relnote, testcase, Whiteboard: relnote-devel (py8ieh: % height and width on object))


(6 files)

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
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. ***
Assignee: amusil → av
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
QA Contact: 3849 → 1698
assigning Eli as QA contact
Closed: 26 years ago
Resolution: --- → FIXED
This can be considered fixed as to original incorrect behaviour
QA Contact: 1698 → 3849
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
Resolution: FIXED → ---
Clearing Fixed resolution due to Reopen.
Target Milestone: M4 → M9
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
Target Milestone: M9 → M11
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
Priority: P2 → P3
Target Milestone: M11 → M14
Lowering priority and moving
QA Contact: beppe → elig
QA Contact: elig → beppe
Hi, Beppe ---

This looks object related; would that be petersen? (it's not me)

QA Contact: beppe → elig
Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.
See also these test cases:
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.
QA Contact: shrir → py8ieh=bugzilla
Target Milestone: M14 → M15
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.  
Target Milestone: M15 → M16
Target Milestone: M16 → M17
*** 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, the XMLhack summaries on, 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.
Keywords: nsbeta3
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

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).
Component: Plug-ins → HTML Element
Keywords: 4xp, html4
Summary: HTML objects are not displayed with object tag → text/html and text/plain OBJECTs don't work
Status Whiteboard:
Keywords: makingtest

This is my first bug, so I can't edit the SW or Keywords fields yet, hence the 

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 

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 to Status Whiteboard.

PS. Welcome, Jamie! :-)
Keywords: testcase
FYI: In addition to IE, this is now supported by Opera, too (starting from 
av, please provide any new information on this bug so we can evaluate it as a 
candidate for beta3- Thanks.
Whiteboard: → [nsbeta3-]
Target Milestone: M17 → Future
This wasn't working in Navigator 4.x. Removing 4xp keyword.
Keywords: 4xpcorrectness
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."
Keywords: relnote
Whiteboard: [nsbeta3-] → [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.
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: [nsbeta3-] relnote-devel → 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 

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
(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.
*** 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
"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.
Keywords: patch
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."

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

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 
In this patch I don't see you deleted old image specific stuff. Shouldn't we do 
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:

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

Closed: 26 years ago23 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.
I found two remaining problem.

Bug 96579: <object> with absolute URL and without MIME type doesn't work
Bug 96580: Changing URL in DATA attribute of OBJECT doesn't take effect

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: relnote-devel → 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
<>. 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.