274033 - <object> specification not respect. no execution of multimedia if clsid present

Status: VERIFIED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Roberto Scano]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MathPlayer 2.0; SV1; .NET CLR 1.1.4322)
Build Identifier: All Mozilla Family Browser

All mozilla family uses type attribute for show object, referring to the 
correct MIME Type. IE family uses CLSID. If I use both the attribute, in 
Firefox and other Mozilla-Family products i haven't the load of the object. It 
seems that Mozilla-Family don't parse object attributes and - if find CLSID - 
don't check if there is also TYPE and DATA.

From HTML 4.01 Spec.

http://www.w3.org/TR/REC-html40/struct/objects.html#adef-classid

classid = uri [CT]
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.

so, can be used TOGHETHER WITH *OR* as an ALTERNATIVE to the data attribute. So 
in this case IE works good. Mozilla-Family uses TYPE:

type = content-type [CI]
This attribute specifies the content type for the data specified by 
data. This attribute is optional but recommended when data is specified 
since it allows the user agent to avoid loading information for 
unsupported content types. If the value of this attribute differs from 
the HTTP Content-Type returned by the server when the object is 
retrieved, the HTTP Content-Type takes precedence.

So, why if there is also CLSID Mozilla-Family browser don't show the object?

Reproducible: Always
Steps to Reproduce:
1. open the url

Actual Results:  
Mozilla-Family browser don't show the object but the alternative text.

Expected Results:  
Identificate the object (using the attribute used always when CLSID is not 
present)

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is invalid.  Using a clsid means that the UA _must_ use a particular binary
plugin (the one matching the clsid) to render the <object>.   If the UA is
unable to use that specific binary, it should show the alternate content; it is
not allowed to substitute some other method of handling the <object> (eg another
plugin).

Now most clsids in use refer to specific ActiveX (hence IE-only) plugins.  Since
those don't work in Mozilla, using such a clsid forces Mozilla to show the
alternate content for the <object>.

See also lengthy discussion on the subject in bug 108557

*** This bug has been marked as a duplicate of 153288 ***

Comment 2

[Roberto Scano]

Sorry but this is a wrong reply.
I don't said: use CLSID instead of "type" and "data".
I'm asking: if a Mozilla-family browser found an object with:

- CLSID
- TYPE
- DATA

where Mozilla-Family need to use TYPE and DATA and *ignore* CLSID for exec the 
plugin and where CLSID could be useful for IE for exec it.

WHY Mozilla, if found all these three attributes, don't use the TYPE and DATA 
and show the object but instead:

1. find object element
2. parse the object attributes
3. find the CLSID
4. ignore that there are other useful attributes like TYPE and DATA
5. don't exec the object

instead of:
1. find object element
2. parse the object attributes
3. find the CLSID and ignore IT
4. read TYPE and DATA
5. exec the object

Comment 3

[Boris Zbarsky [:bzbarsky]]

Because doing what you suggest would be a violation of the HTML spec and lead to
incorrect behavior in some cases (because the wrong plugin would be used).

Please do read the bugs I pointed out.

If you strongly feel that this is really not a duplicate of bug 153288, then
this is invalid on its own merits.

Comment 4

[Mike Kowalski]

v