46569 - Flash Publish codes OBJECT element with IE specific classid attribute

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P4)

Description

[brad]

The attachment has both the <OBJECT> and <EMBED> code for a Flash movie.
The <EMBED> code works, but the <OBJECT> code doesn't.

Reproducible: Always
Steps to Reproduce:
1. Open the attachment.

Actual results:
In the document at the attachment (to be added)
the <OBJECT> version doesn't show up.
   This, despite the fact that OBJECT, and *not* EMBED is
   the correct HTML4.01.

Expected results:
  Either both the OBJECT and EMBED versions should show up, or just the OBJECT
version should show up.

This bug was originally reported as part of
http://bugzilla.mozilla.org/show_bug.cgi?id=44993

Comment 1

[brad]

Attachment: testcase

Comment 2

[sean echevarria]

The object tag should work if instead of specifying a classid you specify a type 
(or is it datatype?).  

I don't think instantiation of plugins via classid works at all.  You certainly 
can't use the 4x Flash plugin as a testcase since there is no way for it to 
notify the browser what classid is associated with it.

Comment 3

[sean echevarria]

Attachment: new testcase

Comment 4

[sean echevarria]

Added a modified testcase.
Added DATA and TYPE attributes to the OBJECT tag.
Removed CLASSID attribute.

Should CLASSID be ignored?  
If not, WHAT should it refer to?
Is the glue code in place to instantiate a plugin based on CLASSID?

Will look into this more later...

Comment 5

[sean echevarria]

changing summary+OS+platform, adding keywords, reassigning

nsObjectFrame::Reflow() (nsObjectFrame.cpp) assumes that if there is a classid 
attribute, then it is used to instantiate an activex control, applet or 
internal widget.  There is no case for instantiating an xpcom plugin by classid.

If you remove the classid attribute from the object tag, then reflow() goes 
down a different path and will correctly instantiate a plugin - xpcom or 4x.

Even if this is fixed for xpcom plugins, 4x plugins will still be broken when 
using object+classid since they don't register a classid with the browser.

Comment 6

[harishd]

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

Comment 7

[Martin Horwath]

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

Comment 8

[ekrock's old account (dead)]

Sean, what is the impact if this is not fixed for RTM?

Comment 9

[sean echevarria]

I don't think this has high impact for the initial release.

N4 does not support loading of plugins by classID.
N6 fully supports the embed tag.
N6 supports embed tags nested within object tags.
I believe macromedia encourages their content developers to use the nested 
embed approach. So for example, if the testcase was written up to have a nested 
embed tag, N6 would display the flash content properly.

This really only affects new content.
To load a plugin, new content should either continue to use embed or not 
specify a classid in the object tag.

Comment 10

[Martin Horwath]

there is only one little problem here. HTML 4.0 Strict has no tag "EMBED". that 
means Mozilla will ignore embed tags nested within object tags.

Comment 11

[sean echevarria]

I stand corrected - thanks Horwath.  I suppose the impact of this depends on how
widespread is HTML 4.0 Strict code that uses plugins.  I'm not familiar with
strict and quirks modes or which is used by default given a particular (or lack
of) doctype, so I can't comment further.

Comment 12

[Braden]

Actually, no version of HTML includes EMBED. (EMBED cannot be accurately
expressed in SGML, of which HTML is an application.)

Adding html4 keyword.

Comment 13

[ekrock's old account (dead)]

Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.

Comment 14

[ekrock's old account (dead)]

Nominating nsbeta1 as this is a "correctness of standards compliance bug" that
significantly obstructs the adoption of features of the standard (in the case,
the OBJECT tag [desired replacement for APPLET] and the CLASSID attribute).

Comment 15

[Peter Lubczynski]

What's with classid? This testcase now works. We never use classid to get a 4.x 
plugin. We check by mimetype of the server or extension. I guess this bug would 
be for XPCOM plugins? What does the spec say? I thought classid was only for 
AcitveX controls. Looking at the code, it almost looks like we once supported 
ActiveX controls, or am I wrong. It would actually be kindof cool to implement 
ActiveX for b/w compatibility with IE. I would write it as an XPCOM plugin 
wrapper similiar to the 4.x ActiveX plugins already out there. If there are any 
that are open source, perhaps we can add them to this project. 

Comment 16

[sean echevarria]

The first testcase is the one that demonstrates the failure to instantiate the
plugin in the object tag.  The second demonstrates that the problem is the
classid (I haven't updated my home moz build in about 2 weeks, but I'm pretty
sure the first testcase is still broken).  I have no idea why there's 'sort of'
classid support in nsObjectFrame::Reflow() (nsObjectFrame.cpp).

Comment 17

[bcortez]

Mozilla Build ID: 2001060116

This may or may not be related, however, the OBJECT tag does not properly handle
the failure of an OBJECT rendering as per the HTML 4.01 specification. (test
case URL will follow if requested)  

See W3C HTML 4.01 specification at: 
http://www.w3.org/TR/html401/struct/objects.html#edef-OBJECT

Specifically, Section:  13.3.1 Rules for rendering objects
which states,



One significant consequence of the OBJECT element's design is that it offers a
mechanism for specifying alternate object renderings; each embedded OBJECT
declaration may specify alternate content types. If a user agent cannot render
the outermost OBJECT, it tries to render the contents, which may be another
OBJECT element, etc.

In the following example, we embed several OBJECT declarations to illustrate how
alternate renderings work. A user agent will attempt to render the first OBJECT
element it can, in the following order: (1) an Earth applet written in the
Python language, (2) an MPEG animation of the Earth, (3) a GIF image of the
Earth, (4) alternate text.

<P>                 <!-- First, try the Python applet -->
<OBJECT title="The Earth as seen from space" 
        classid="http://www.observer.mars/TheEarth.py">
                    <!-- Else, try the MPEG video -->
  <OBJECT data="TheEarth.mpeg" type="application/mpeg">
                    <!-- Else, try the GIF image -->
    <OBJECT data="TheEarth.gif" type="image/gif">
                    <!-- Else render the text -->
     The <STRONG>Earth</STRONG> as seen from space.
    </OBJECT>
  </OBJECT>
</OBJECT>

The outermost declaration specifies an applet that requires no data or initial
values. The second declaration specifies an MPEG animation and, since it does
not define the location of an implementation to handle MPEG, relies on the user
agent to handle the animation. We also set the type attribute so that a user
agent that knows it cannot render MPEG will not bother to retrieve
"TheEarth.mpeg" from the network. The third declaration specifies the location
of a GIF file and furnishes alternate text in case all other mechanisms fail.

Comment 18

[bcortez]

This is pre-stated in the HTML4 spec as well located at:
http://www.w3.org/TR/html4/struct/objects.html#h-13.3.1

Comment 19

[bcortez]

Sorry for the multiple posts, I forgot to mention the error I was experiencing.
The failure I referred to above is that even if the OBJECT successfully
renders, the alternate object is still rendered when it shouldn't. The
alternate object should only be rendered if the primary object fails to render.
In the case below, the JVM will successfully load and instantiate the JAVA
applet. Following the applet instantiation, the error image displays along with
the error text.

eg:

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F49XXXX"
width="100%"
height="20%"
align="baseline"
codebase="http://someserver/plugins/jre131_pank.cab#Version=1,3,1,0">

<!-- Else, try the GIF image -->
<IMG id="ErrorImage" src="/wfc/html/debug/images/ObjectError.gif" hspace='5'>
<!-- Then render the text -->
<STRONG>The JRE Failed to properly load. Please contact your system
administrator.</STRONG>

<PARAM NAME="code" VALUE="TestApplet.class">
<PARAM NAME="codebase" VALUE="/classlib">
<PARAM NAME="type" VALUE="application/x-java-applet;version=1.3">
</OBJECT>

Comment 20

[Peter Lubczynski]

cc:ing Chris Karnaze as I recall him working with some of that code recently.

Comment 21

[karnaze (gone)]

Regarding the example in the 2001-06-04 11:48 comments - I'm not getting the 
applet to load because of the following code in nsObjectFrame::Reflow which I 
don't understand.

      if (classid.Find("java:") != -1) {
        classid.Cut(0, 5); // Strip off the "java:". What's left is the class 
file.
        bJavaObject = PR_TRUE;
      }

      if (classid.Find("clsid:") != -1) {
        classid.Cut(0, 6); // Strip off the "clsid:". What's left is the class 
ID.
        bJavaPluginClsid = (classid.EqualsWithConversion(JAVA_CLASS_ID));
      }

------

However, when I substitute a plugin for the applet and it is found, then I don't 
see the problem of displaying the alternate.

<OBJECT name="videoNN" type="audio/x-pn-realaudio-plugin" 
src="http://video.cnet.com:80/cnet_news/template/ramgen.cgi?cpcode=674&asset=htt
p://cnetnews.download.akamai.com/674/t010601_1200hi.rm&start=5166&end=695300&xtn
=.ram" width="320" height="240" hspace="0" vspace="0" border="0" 
controls="ImageWindow" autostart="true" loop="false" console="ClipNN">

<IMG id="ErrorImage" src="/wfc/html/debug/images/ObjectError.gif" hspace='5'>
<STRONG>The JRE Failed to properly load. Please contact your system
administrator.</STRONG>
</OBJECT>

Comment 22

[bcortez]

I just confirmed Chris' statement above.  It seems it only fails when there is 
a JAVA applet specified in the OBJECT tag.  Is there a specific MIME-TYPE that 
I should be using for a JAVA applet in place of a CLASSID in the OBJECT tag?

Is there any (anticipated) progress on this bug lately?

Thanks... :)

Comment 23

[bcortez]

I think I may have tracked down where this problem lies in the CPP code.  

Source File: nsObjectFrame.cpp
Line(s): 744 - 759

The error seems to be located on line 757 where it passes the 'classid' to the 
NS_NewURI funtion instead of the 'codeBase'.  If the 'codeBase' was passed, it 
should then construct absolute (fullURL) and process away...

I've included the offending code block below (for readability sake), the actual 
errror may be line 757.

(I don't have the facilites to compile this code myself, could someone verify 
my hypothesis here?)

------------------------


744         nsAutoString codeBase;
745         if ((NS_CONTENT_ATTR_HAS_VALUE == 
746              mContent->GetAttribute(kNameSpaceID_HTML, 
nsHTMLAtoms::codebase, codeBase)) && 
747             !bJavaPluginClsid) {
748           nsCOMPtr<nsIURI> codeBaseURL;
749           rv = NS_NewURI(getter_AddRefs(codeBaseURL), codeBase, baseURL);
750           if (NS_SUCCEEDED(rv)) {
751             baseURL = codeBaseURL;
752           }
753         }
754 
755         // Create an absolute URL
756         if(bJavaPluginClsid) {
757           rv = NS_NewURI(getter_AddRefs(fullURL), classid, baseURL);
758         }
759         else fullURL = baseURL


------------------------

Thanks....

Comment 24

[bcortez]

I've been wading through this code history all night, and here are some of my 
findings which I believe are contributing these problems.


==============

Source Filename: /layout/html/base/src/nsObjectFrame.cpp

Method: nsObjectFrame::Reflow(nsIPresContext*          aPresContext,
                              nsHTMLReflowMetrics&     aMetrics,
                              const nsHTMLReflowState& aReflowState,
                              nsReflowStatus&          aStatus)





This entire section was re-coded in Rev 1.216 by karnaze on May 18, 2001 
(bugfix for #64645), and introduced some subtle side-effects concerning the 
return status of the Reflow method.  This method now returns NS_OK in 
situations where the object was never truly instantiated.  Therefore, the 
ReflowChild also never fails.



899   // finish up
900   if (NS_SUCCEEDED(rv)) {
901     NotifyContentObjectWrapper();
902   }
903   else {

This line incorrectly sets 'rv' to NS_OK since NS_SUCCEEDED(rv) obviously 
failed or we wouldn't be here).  This results in a fall-through side-effect 
(see line 928).

904     rv = NS_OK;
905     // reflow the 1st object frame child as an alternate. If there is none, 
906     // then display our alternative content with CantRenderReplacedElement()
907     nsIFrame* childFrame = mFrames.FirstChild();
908     while (childFrame) {
909       nsCOMPtr<nsIAtom> frameType;
910       childFrame->GetFrameType(getter_AddRefs(frameType));
911       if (frameType.get() == nsLayoutAtoms::objectFrame) {
912         nsHTMLReflowState childRS(aPresContext, aReflowState, childFrame,
913                                   nsSize(aReflowState.availableWidth, 
aReflowState.availableHeight));
914         // reflow the child object frame and let it set rv, aStatus
915         return ReflowChild(childFrame, aPresContext, aMetrics, childRS,
916                            0, 0, NS_FRAME_NO_MOVE_FRAME, aStatus);
917       }
918       childFrame->GetNextSibling(&childFrame);
919     }
920     // there was no object frame child, so render the content

At this point, the object/plugin has still failed to instantiate (this affects 
the child objects as well since 'ReflowChild' (see line 915) calls 'Reflow' and 
this code will be used).

921     nsCOMPtr<nsIPresShell> presShell;
922     aPresContext->GetShell(getter_AddRefs(presShell));
923     presShell->CantRenderReplacedElement(aPresContext, this);
924   }
925 

Here, the 'aStatus' will always be set to NS_FRAME_COMPLETE.  This isn't true 
if the object failed to instantiate.....right?  ALL consumers will (mistakenly) 
assume that the object is there.

(NOTE: This line along with the classid I mentioned previously were introduced 
in Rev 1.60 as "prelim code for ActiveX support" by amusil@netscape on Mar 21, 
1999.  This is DEBUG code that has lain dormant here for over 2 years now, just 
waiting to strike.)
 
926   aStatus = NS_FRAME_COMPLETE;
927 

At this point however, 'rv' is still set to NS_OK (see line 904).  'rv' should 
not be set to NS_OK in line 904, so that the failed value of 'rv' can be 
bubbled upward upon return...


928   return rv;
929 }

==============


I hope this helps out you guys a bit in tracking down these nasties.  I'd like 
to think I helped get the OBJECT tag working with JAVA plugins, Kronos is using 
the OBJECT tag in this manner now.  I am fighting a ruthless battle with 
project management to keep support alive for Mozilla/Netscape6.

Keep up the great work you guys!!  :)

Comment 25

[karnaze (gone)]

bcortez, I tried your suggestion after changing

#define JAVA_CLASS_ID "D27CDB6E-AE6D-11cf-96B8-444553540000"

but then the following failed:

        rv = InstantiatePlugin(aPresContext, aMetrics, aReflowState,
                               pluginHost, "application/x-java-vm", fullURL);

------

You are right that the return codes in nsObjectFrame::Reflow need some 
work. However, I don't think the callers are paying much attention to the return 
codes right now. aStatus being set to NS_FRAME_COMPLETE indicates that 
the object frame cannot split (for printing) and that is probably ok.

Comment 26

[bcortez]

This probably failed because the JAVA_CLASS_ID is now incorrect (which means it 
should fail). The classid supplied in the HTML OBJECT tag will be the one 
below.  If youchange the one defined in the nsObjectFrame.cpp, when it does its 
comparison on line [bJavaPluginClsid = (classid.EqualsWithConversion
(JAVA_CLASS_ID));], it will fail since they no longer match.  The ortiginal 
JAVA_CLASS_ID was correct, you don't need to change it at all.



This is the correct Java Class ID

#define JAVA_CLASS_ID "8AD9C840-044E-11D1-B3E9-00805F499D93"


As for the return codes, there is one caller (ReflowChild) which does matter.  
If the 1st object child fails, it will not move on the the 2nd, 3rd, etc...
Also, if the user intends to trigger on this failure mechanism (using the 2nd 
object child to indicate the plugin failed to init), then this will never work.

I am using this child-object mechanism as per the W3C specs for the OBJECT 
tag.  I have an error IMG I am using as a 2nd object child.  If this object is 
instantiated, I know the plugin failed to init.  Using the onLoad event of the 
IMG I can trigger some action to occur (pop up an alert, open a new window with 
the plugin update page, etc...) if this IMG gets loaded.  I am currently using 
this successfully in MSIE,  and want to help get Mozilla/Netscape6 up to speed 
as well.

Thanks for your efforts...  :)

Comment 27

[Peter Lubczynski]

cc:ing some Java folks and Andrei!

Comment 28

[drapeau]

Copying Stanley Ho of the Java Plug-In group.

Comment 29

[bcortez]

Has there been any progress toward testing my suggested fixes for this bug?

Comment 30

[Blake Ross]

Missed 0.9.3.

Comment 31

[av (gone)]

-->0.9.5

Comment 32

[Phil Anderton]

Has anyone else noticed that the second testcase is broken in MSIE, i.e. the
OBJECT tag does not work if CLASSID is *not* specified?
To get this to work in both IE and Mozilla, one needs to nest an OBJECT with
CLASSID inside an OBJECT  with DATA and TYPE.

Comment 33

[karnaze (gone)]

Reassigning to av.

Comment 34

[sean echevarria]

>Has anyone else noticed that the second testcase is broken in MSIE, i.e. the
>OBJECT tag does not work if CLASSID is *not* specified?

I didn't mean to imply that it was supposed to work in IE.  The CLASSID is 
required for IE to know what ActiveX object is to be instantiated.

Comment 35

[Phil Anderton]

Sean, my point is that CLASSID is always going to be there, simply because IE 
requires it. We must live with that. Nesting the same <OBJECT> within itself 
(but with different syntax) is not exactly optimal either. It would be nice if 
we could say to web designers "specify *all* these attributes (CLASSID, DATA, 
TYPE) and it will work in both browsers". 
Can someone explain why Mozilla can't simply ignore CLASSID in this case?

Comment 36

[Phil Anderton]

I'm attaching a simple patch to fall through to the "normal" plug-in code for
the case when CLASSID is specified, and the "check to see if we have an ActiveX
handler" fails. This is almost certainly too simple, but it seems to work for me
- a Flash <OBJECT> with CLASSID, SRC and DATA is viewable in both Mozilla and IE.

Comment 37

[Phil Anderton]

Attachment: Simple patch

Comment 38

[TGOS]

IE does *NOT* always need the CLASSID when the OBJECT tag is used.

See:
http://tgos.org/object/index3.html

The code to embed RealPlayer here is:

<object id="player1" type="audio/x-pn-realaudio-plugin"
 height="26" width="44">
	<param name="controls" value="PlayButton">
	<param name="console" value="clip1">
	<param name="src" value="test1.rm">
</object>

As you can see, no CLASSID. Also no DATA is provided, that's what the SRC
paramter is good for. In Mozilla it doesn't work, as Mozilla ignores all PARAM
tags. That's why I created bug 99063 (go there for more information).

Most annoying is that the following code works in Mozilla:

<object id="player1" type="audio/x-pn-realaudio-plugin"
 height="26" width="44" controls="PlayButton" console="clip1"
 src="test1.rm">
</object>

See here: http://tgos.org/object/index4.html

Although no DATA attribute is given there either, however I'm not sure if it
MUST be provided according to HTML4 specification. The problem is that the
index4.html page is not HTML4 comform anymore, because the OBJECT tag doesn't
know any paramters like CONTROLS, CONSOLE or SRC. And it doesn't work in IE,
because IE ignores those paramter now (the result looks like in the second code
example where Mozilla ignored the PARAM tags).

That's why I said at the other bug, that Mozilla treats the OBJECT tag like
EMBED where all parmaters are given in the tag and not like APPLET, where all
paramters are given via PARAM tags.

Comment 39

[Phil Anderton]

Could it be that http://tgos.org/object/index3.html triggers the Netscape plugin
support that Microsoft have so graciously removed from IE6?

The DATA attribute is not mandatory according to the HTML4 spec.

Comment 40

[av (gone)]

The patch fixes the problem reported. The question is: should we do this? Do we 
have a concensus?

Comment 41

[av (gone)]

Probably not critical for 0.9.5

Comment 42

[Val Sharp]

Bear in mind, though, that I came across this because I used 'Publish' in Flash 
to create the HTML to embed the movie - it was Flash itself that wrote an OBJECT 
tag with a CLASSID attribute.

I imagine therefore that this problem might be more common than we imagine.

Comment 43

[rubydoo123]

adding WRMB

Comment 44

[Peter Lubczynski]

I don't think this should be fixed for quirks mode because then we won't use the
almost always nested EMBED tag which is what the HTML author intended for
4.x-style plugins. This should be fixed for standards mode.

Comment 45

[rubydoo123]

added topembed and bugscape ref

Comment 46

[Peter Lubczynski]

Attachment: patch for strict mode

Comment 47

[Peter Lubczynski]

I've attached a patch to fix for this HTML standards mode only with an
explaination but I'm thinking this bug shold be marked WONTFIX or depends on
implementing ActiveX in Mozilla.

ActiveX controls are not the same as Netscape plugins. There are things Netscape
plugins know how to do that ActiveX controls don't and vice versa. One of these
is parsing the PARAM tags. Most plugins don't do this correctly.

The patch still won't make the first testcase work in Mozilla because it's not
valid, comparing ActiveX controls with plugins. ActiveX controls are NOT plugins
and in order to use Flash with the following HTML code we need to support ActiveX:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
 codebase="http://active.macromedia.com/flash2/cabs/swflash.cab#version=4,0,0,0"
 ID=Flower WIDTH=350 HEIGHT=200>
<param NAME=movie
VALUE="http://members.netscapeonline.co.uk/valeriegsharp/object1-test/Flower.swf">
</object>

The classid points to a specific binary implementation the author wanted to use.
Since we don't support ActiveX, we won't be able to render this tag and should
try the contents. In fact, on non-Win32 platforms, based on the above tag, how
could Mozilla determine this is intended for the Flash plugin? There needs to be
at least a data attribute with the URL for the movie to try.

Possible Solutions on how to stay HTML compliant:
1) Check-in my patch and you can use one OBJECT tag for both IE and Mozilla. It
IE it will invoke an AcitveX control based on the classid or in Mozilla the
plugin based on the mime-type in the type attribute. The only minor isssue is
the data attribute should point to the movie source in order to work in Mozilla.
You'll also have to set the correct DOCTYPE at the top of the document because
we default to quirks mode without one.
2) Install an ActiveX handler (or other means) that will be able to understand
the classid. This solution will generaly only work on Win32 platforms. There is
one you can try in the mozilla source, under embedding.
3) Use nested object tags (the best solution, IMO). The outer tag should attempt
to use the ActiveX control and the inner one should try the plugin.

Comment 48

[Peter Lubczynski]

Attachment: strict mode testcase that works with previous patch - one OBJECT tag works in both browsers

Comment 49

[Peter Lubczynski]

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

Comment 50

[Marek Z. Jeziorek]

corresponding bugscape bug is not P1 -- removing topembed

Comment 51

[Braden]

Actually, Peter, I think the CLSID usually refers to *someone's*
implementation--it does not refer to a "specific binary representation". What I
mean here is that CLSIDs should be expected keep working when, say, a new
version of Flash is released (as long as the new version can play the old
version's content). In fact, the new version might have multiple CLSIDs that can
be used: one specific to the new version (and useful for content that doesn't
run in the old player), and one shared with the old version.

I've proposed this before: Why not enhance the Mozilla XPCOM plugin API to
support this notion of CLSIDs? That way Mozilla plugins could advertise the same
support as their ActiveX counterparts.

Comment 52

[Peter Lubczynski]

It would be nice if the NP-API provided a classid, maybe you should file a bug.
NPAPI was written before the OBJECT tag came to spec. The depricated XPCOM
plugin API did provide a way for plugins vendors to implement a classid.

However, I think it may be a long time before web users starting having
installed 4x-style NP plugins that recognize classid. I think the classid would
have to change because NP plugins across multiple platforms don't support
everything that ActiveX does and vice versa.

"Publish" facilities in HTML authoring products should be sensitive to NP
plugins. For example, FrontPage can either insert a "Plugin" or an "ActiveX
Control". Notice the difference in output. HTML auhtors should take care and be
evangelized to use the correct option for their target audience.

Moving to 1.0 for now....

Comment 53

[Braden]

Whoa... So the XPCOM plugin API is now deprecated? That's news to me. I can't
say I'm surprised, though... It kinda sucked. Its heart was in the right place,
though. Will there be a new XPCOM plugin API, or is the old Netscape API "it"
for the forseeable future?

In general, I don't think we should be catering to the differences between
ActiveX controls and Netscape plugins. We should be aspiring to a world where
authors can use an OBJECT tag and it Just Works, regardless of whether users are
using IE or Mozilla.

Comment 54

[Alfonso Martinez]

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

Comment 55

[Koike Kazuhiko]

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

Comment 56

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 57

[Martin Horwath]

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

Comment 58

[Steve]

Mozilla 0.9.8+
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.8+) Gecko/20020215

I'm using the object tag to present SVG in a HTML doc and offer a png screen
shot to non enabled browsers. 
The code being used is pasted below and it works except in Opera, Opera is
picking up the SVG image. If I change from data to userid then all browsers get
the png, even the SVG enabled.

<object style="background-color:#99ffff; overflow: hidden; 
-moz-border-radius:5px; border: Fuchsia 5px ridge;"    data="xmlimages/moz.xml"
type="application/xhtml+xml"    width="180px" height="86px" ><img
src="images/toe.gif" alt="" border="2"/ >
</object>

To see this working go to either
http://www.skeeter-s.com/svg/object-test_1.html
or to the start page
http://www.skeeter-s.com/svg/
It too contains an SVG image that is coming in via the object tag.
To view the SVG one needs the right browser of course.
Any ideas here?  

Comment 59

[Henrik Gemal]

is this the main bug for getting Windows Media Player to work only with 
<object> and no <embed>?

Comment 60

[Henrik Gemal]

Attachment: Windows Media Player testcase

Comment 61

[Peter Lubczynski]

Comment on attachment 86575 [details]
Windows Media Player testcase

This testcase is invalid because you are using the ActiveX syntax for the
OBJECT tag. Gecko has no way of knowing how to map Windows-only ActiveX
classids to Netscape style plugins plus they don't always respond to the same
parameters and script.

Using this syntax, you can use the OBJECT tag with WMP with Gecko:
<OBJECT
  ID="mediaPlayer"  
  type="application/x-mplayer2"  
 
CODEBASE="http://activex.microsoft.com/activex/controls/mplayer/en/nsmp2inf.cab
#Version=5,1,52,701"
  width=200 height=200>
  <PARAM NAME="fileName"
VALUE="http://hotwired.lycos.com/webmonkey/radio/WMRadio7.mp3">
  <PARAM NAME="showControls" VALUE="true">
</OBJECT>

Comment 62

[Peter Lubczynski]

Pushing out to 1.2, although I think this bug may be invalid. We can not map
ActiveX classid to Netscape style plugins.

That last testcase, the single object tag without using classid at all, works
for me in both IE 6 and NS 7. 

Comment 63

[rubydoo123]

The classid attribute is optional, not required for the user agent. Choosing to
use clsid prefix within the classid attribute is an IE specific extension.
Netscape renders the plug-in if the type and/or data attributes are present. If
you wish to use one object element, then you would want to use the type and data
attributes, not the classid attribute with a specific implementors prefix extention.

I am inclined to agree with peterl, this is really an invalid bug

Comment 64

[Alfonso Martinez]

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

Comment 65

[rubydoo123]

The problem here is that if the author is pointing to an ActiveX file in the
classid, then it is likely that the other attributes such as data, codebase and
type are referencing that ActiveX instance. The most reliable method is either
to do one of these two options:

1. nest object elements, one defining ActiveX and one defining plug-in instance
via data and type. Defining an Applet should be done as always.
2. do not use classid="clssid: nnnn", and just use type and data to define a
plug-in instance.

Comment 66

[Bill Mason]

I'd like to suggest that if this bug is teetering toward invalid, that it should
instead at least go over to Evangelism based on comment 42, where it is noted
that the Macromedia software itself writes IE-specific coding.

And FWIW, while I know of one person who has gotten nested OBJECT tags to work
correctly in IE, every time I try it IE tries to load both OBJECTs.  The
"plugin" one fails but IE still leaves space in the page layout for it.

Comment 67

[rubydoo123]

I hope no one minds, but I am going to change the Summary based on comment #42
setting dependency on Flash meta tracking bug 139820 and assigning to evang

I am not clear as to why this bug would block bug 7954 - supporting a Microsoft
extension in the classid attribute does not seem relavent. Nor does it seem
relavent that only one object element be required, the purpose for nesting
object elements is to allow authors to point ot differing implementations.

Nor do I understand why this would be tracked in the embedding meta bug

Comment 68

[Braden]

Looking back over the comments, it looks like this bug has been about different
things over the course of its existence. At the very least, it has meant
different things to different people. In its current incarnation, it is not a
blocker for bug 7954.

Comment 69

[Christopher Hoess (gone)]

Per the last few comments, removing html4 and the standards tag in the 
whiteboard.

Comment 70

[David Eccles]

Okay, here's my two cents worth. I am writing code for a web page that plays a
sound object when clicking on it. I want to be able to write a single object
that will play in both IE and Mozilla (I am currently running 1.1), writing one
batch of code, using no if statements or similar. From what I have done already,
this is almost possible, with one sticking point.

The following code will work correctly in IE (if the correct plug-in is loaded):
<OBJECT classid="CLSID:05589FA1-C356-11CE-BF01-00AA0055595A" data="pikachu.wav"
type="audio/x-wav" autostart=true id="pikachu.wav">
	<PARAM NAME=src VALUE="pikachu.wav">
	<PARAM NAME=showcontrols VALUE=false>
	<PARAM NAME=showdisplay VALUE=false>
	<PARAM NAME=autostart VALUE=true>
</OBJECT>
This code will not work in Mozilla, I need to remove the classid bit as follows:
<OBJECT data="pikachu.wav" type="audio/x-wav" autostart=true id="pikachu.wav">
	<PARAM NAME=src VALUE="pikachu.wav">
	<PARAM NAME=showcontrols VALUE=false>
	<PARAM NAME=showdisplay VALUE=false>
	<PARAM NAME=autostart VALUE=true>
</OBJECT>
[taken from http://gringer.dis.org.nz/xamp.html]

Looking at the w3c pages
(http://www.w3.org/TR/REC-html40/struct/objects.html#edef-OBJECT), I see that
classid is specified as an attribute in object. I don't care if Mozilla does not
invoke ActiveX when it sees the classid. Perhaps it could accept classid as an
attribute, but ignore its contents.

Comment 71

[Braden]

Nope. CLASSID is used to specify a particular implementation. If a user agent
doesn't support the specified implementation, it should not render the OBJECT.

If you must use CLASSID, you can have a nested OBJECT as alternate content in
the event that your preferred implementation is unavailable.

Mozilla is doing the Right Thing here. If what Mozilla is doing were changed, it
would then be doing the Wrong Thing.

Removing 4xp and patch keywords. We don't want parity with 4.x's buggy OBJECT
implementation, and the patches here shouldn't be applied.

Comment 72

[Arun Ranganathan]

Further to Comment 70 :

David, it is indeed possible to use one object tag.  IE will understand if you
use an object tag with the type attribute:

<object type="application/x-shockwave-flash"....

Try that.

Comment 73

[Bill Mason]

The new ALA outlines pretty well how to make one OBJECT tag work cross-browser
for Flash:
http://www.alistapart.com/stories/flashsatay/

Comment 74

[Brant Gurganus]

I am sending this to the plugins people to see if the patches attached are still
applicable.  If not, I think this will be a WONTFIX or INVALID.

Comment 75

[Ryan Gammon]

I have a project at http://iestreamconv.mozdev.org that maps classid's to types
for a couple of the common plugins.

Comment 76

[Bill Mason]

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

Comment 77

[u102922]

In IE it is not necessary to include the classid attribute and it works fine.

Example :

<OBJECT id="content" width="100%" height="300px" type="application/pdf">
    <PARAM name="src" value="test.pdf">
</OBJECT>

Comment 78

[Bill Mason]

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

Comment 79

[Maarten Brouwers]

First; quicktime has the same problem...

-sorry for double posting this into bug 208024 wich i think relates to this bug... -

I'd like to quote Braden;

"Nope. CLASSID is used to specify a particular implementation. If a user agent
doesn't support the specified implementation, it should not render the OBJECT."

What to think of the following code to implement quicktime? Valid (X)HTML, IE
accepts it, but Mozilla nogo:

<object classid="test.mov" data="test.mov" type="video/quicktime"
style="width:380px; height:285px;">		
	 <p>Error Text or alternative object, or alternative image...</p>
</object>

The w3 site states about the classid attribute:

"This attribute may be used to specify the location of an object's
implementation via a URI. It may be used together with, or as an alternative to
the data attribute, depending on the type of object involved."

note the part 'alternative to the data attribute'.

Please reconsider this.
(or there should be better arguments ;) )

Comment 80

[Braden]

I think that's an abuse of the classid attribute. It's meant to identify a
*runtime*--not data for a runtime.

I don't even see what your proposal tries to accomplish. It wouldn't do anything
to fix the pages that are needlessly broken for Mozilla.

Resolving WONTFIX. (Bug 208024, however, is legitimate. But your proposal is not
appropriate for it, either.)