OBJECT element alternate content is not displayed. Instead, the rectangle the *primary* content would normally occupy is never redrawn.

We talked awhile ago about having troy help michael write some code to handle this so that the alternate content would be used when a plugin isn't found... So I'm assigning it to troy

Alex, this is a plug-in bug. You'll want to talk with Michael (and me or Kipp) about how best to implement it

Andrei Volkov is going to own object tag handling

Putting on ss: radar

Per rickg, not an ss: bug. Pulling off ss: list.

Andrei - can you meet with Kipp and/or Troy sometime in the next few days to go over object tag issues?

Here's some more info from the old 5.0-"classic" codebase: We need to make sure that the same object tag that JavaSoft uses in IE works in 5.0. JavaSoft needs this sometime before Sept 1 in order to put together a beta for us. I think this means making <object classid=clsid:...> be able to specify a JVM (I think this is what they do for IE). We may also want to add some kind of version information so that users can say "I want to run in any jvm that supports 1.2 or greater", e.g.: <object type="application/x-java-vm;version=1.2;mfg=JavaSoft" ...> (extensions to the type attribute), or additional attributes: <object type=application/x-java-vm version=1.2 mfg=JavaSoft> ------- Additional Comments From warren 07/09/98 14:24 ------- Here's what they want... Subject: proposal for <OBJECT> tag in Navigator 5 Date: Mon, 06 Jul 1998 13:37:51 -0700 From: Graham Hamilton <kgh@zebadee> To: robsz@zebadee, stanleyh@zebadee CC: kgh@zebadee, dochez@zebadee Here's a suggestion for what to propose to Netscape on the <OBJECT> tag. Comments appreciated. - Graham Goals: We'd like to have Navigator support the same form of <OBJECT> tag that we use to invoke the Java Plug-in under IE. This makes it easier for developers to write portable HTML. Here's a sample: <OBJECT WIDTH=275 HEIGHT=30 align="baseline" border="0" CLASSID="CLSID:8aAD9C840-044E-11D1-B3E9-00805F499D93" codebase="http://javaweb.eng//jinstall-111-win32.cab#Version= 1,1,1,0"> <PARAM NAME="code" VALUE="Clock2.class"> <PARAM NAME="FontFamily" VALUE="Courier"> </OBJECT> We'd like to make it easy for Navigator to support. We'd like to make it somewhat flexible, so that other peopple can also use the same syntax with different CLSIDs. Proposal: When an <OBJECT> tag is encountered with a Microsft style CLASSID (i.e. one where the value starts with "CLSID:") Navigator should simply activate a plug-in, where: (1) The Plugin's MIME type is the CLASSID value. So the Java Plug-in would support the MIME type CLSID:8AD9C840-044E-11D1-B3E9-00805F499D93 (2) Navigator would recognize and implement the WIDTH, HEIGHT, ALIGN, ID, and BORDER parameters to the OBJECT tag in the normal way. (3) All the tag=value pairs in the <OBJECT> tag and all the PARAM/VALUE tags in the <OBJECT> body are passed as parameters to the plugin. (4) Navigator would ignore the codebase parameter. So you need to have a suitable plugin already installed. Rationale: It's a little hokey, but it's reusing lot of existing mechanism. This is very similar to how Navigator 4 already deals with <OBJECT> tags, except we are using CLASSID rather than TYPE to obtain the MIME type. So hopefully it should be easy to implement. Because we simply use the CLASSID as the Mime type, it's easy for us (and for others) to deliver plugins that work with specific Microsoft COM object ids.

installing myself as QA Contact en masse

Cannot verify as crasher at plugin invocation present on Mac, but looks fixed on Win and Linux in March 19 Seamonkey builds. Marking verified.

This one is back, in 1999112208. The gray "object" box is now drawn instead of the alternate content.

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

Attaching a minimized test case and clarifying the bug report: Overview description: Mozilla doesn't display OBJECT element contents when the OBJECT itself cannot be displayed. Steps to reproduce: 1) View the attachment "Minimized test case". Actual results: A gray box sized 100*100 pixels. Expected results: Since the MIME-type is unknown and there is no 'data' attribute, the element content saying "This is the alternate content" should be displayed - not inside a 100*100 box but just like any HTML text paragraph. Build date & platform: Originally reported 1998-09-12 on an unknown build. Additional builds and platforms: Dec 19, 1999 installer build on Windows NT 4.0 SP6.

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

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 (this one), bug 15019 and bug 22047 respectively, see also bug 678. (Marking M14 like bug 15019.) The content of the OBJECT element should be rendered just as if the OBJECT element was a generic container, like <DIV>. Styles that apply to it should be used (such as the 'height' and 'width' attributes if it has 'display:block') but no new styles should be introduced (such as a border or background) unless these are explicitly mentioned in some stylesheet. The code used for the <IMG> element's alternate content (namely, CantRenderReplacedContent) should be used here. See bug 1994 and Troy for more information. Glynn: 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.

s/bug 22047/bug 22037/ shoot py8ieh=bugzilla@bath.ac.uk

I see no alternate content at http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/object-unknown.html on 1999122208 nightly build (Windows98) - there's just a gray box saying "object". Did someone using a previous build actually see the alternate content in the box - or is the changed summary just a result of a misunderstanding?

The original failure described in this bug report is for the OBJECT element alternate content not being displayed. If the style that apply to it is wrong (i.e. gray background), it should be reported in a separate bug report.

Changed summary to reflect actual nature of this bug.

Tested under Win 98 (2000011008) and Mac OS 9 (2000010611). The result is the same as reported: The object's alternative text is not rendered on either mac or windows. Win 98: Using the test case provided, I get a grey rectangle labeled "Object" instead of the alt text. I would expect the alt text to appear instead since the object's format is unknown. Mac 0S 9: Using the test case provided, I get a blank window with no alt text or a grey rectangle like Win 98. The expected result would be the appearance of the alt text.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Checked in the fix.

Works beautifully on build 2000020817 (WinNT4 SP6). Marking Verified/Fixed.

Reopening. Alternate contents is not displayed using 2000042708 build on Windows 2000.

Linux build 2000-04-24-09 (Red Hat 6.2, kernel 2.2.14) is also broken. Changing OS to All.

Changing milestone since M14 is out.

If the object src can't be rendered, it's contents should be. Added nsbeta2 to keyword.

Fixing this bug seems to be removed by linux legacy plug-in support. rusty.lynch@intel.com?

Ahhh! There is a hole in the logic for nsPluginHostImpl::InstantiateEmbededPlugin(). I will attach a patch.

removed self from cc list. sounds like this is under control. av, can you review the patch? thanks!

I applied the patch and it seems to be working. rusty, do you want me check it in? Or you can use r=av.

I am going to apply the patch this evening from home.

ok, the patch is checked in. This enables alternate content on object tags that have an unknown type.

Marking fixed. Thanks.

Works in the May 22nd build. Marking verified fixed.

It's back again.

Putting on [nsbeta2-] radar. Not critical to beta2.

I'm not seeing this on a debug or release Linux build (build id #2000061408).

Works for me on WinNT4 build 2000-06-24-08, too.

Yup; now working for me again, too. Marking fixed.

Verified fixed in the June 25th builds (2000062508).