153288 - XHTML compliant way of displaying flash not supported

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[James Cho]

From Bugzilla Helper:
User-Agent: ShonenScape
BuildID:    2002053012

The only XHTML compliant way of integrating Flash (using <object> and <param>) is not supported by Mozilla.  Here is an example of correct compliant Flash usage:
"<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,0,0" width="478" height="58">
<param name="movie" value="topmidhdr1.swf" />
<param name="quality" value="high" />
<param name="menu" value="false" />
</object>"

The non XHTML compliant way can be used though (the <embed> tag)



Reproducible: Always
Steps to Reproduce:
Blip

Actual Results:  Bloop

Expected Results:  Blop

Bleep

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->Plugins

Comment 2

[Boris Zbarsky [:bzbarsky]]

confirm

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, apparently the |classid| attribute there is something odd... see discussion
in bug 108557

Comment 4

[Peter Lubczynski]

--->INVALID  That's IE ActiveX HTML for OBJECT tag. How could Gecko browsers on
Mac or Linux be able to guess what ActiveX CLASSID maps to which plugin?

Use Mozilla syntax, for example:
<object data="http://www.macromedia.com/shockwave/download/triggerpages/flash.swf" 
        type="application/x-shockwave-flash"    
codebase="ftp://ftp.netscape.com/pub/netscape7/english/7.0_PR1/windows/win32/xpi/flash.xpi"

        width="478" height="58">
<param name="quality" value="high" />
<param name="menu" value="false" />
</object>

Comment 5

[Boris Zbarsky [:bzbarsky]]

James, does this work if you add a "type" attribute with the correct MIME type
to your object?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Joe Chou]

Try a simple object tag like:

<object type="application/x-java-applet" code=FirstApplet.class WIDTH= 50%
HEIGHT = 100> </object>

That should work.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Roberto Scano]

(In reply to comment #4)
> --->INVALID  That's IE ActiveX HTML for OBJECT tag. How could Gecko browsers 
on
> Mac or Linux be able to guess what ActiveX CLASSID maps to which plugin?
> Use Mozilla syntax, for example:
> <object 
data="http://www.macromedia.com/shockwave/download/triggerpages/flash.swf" 
>         type="application/x-shockwave-flash"    
> 
codebase="ftp://ftp.netscape.com/pub/netscape7/english/7.0_PR1/windows/win32/xpi
/flash.xpi"
>         width="478" height="58">
> <param name="quality" value="high" />
> <param name="menu" value="false" />
> </object>

Sorry a question referring to 274033 that I've opened without a right reply.
First: CLSID is not a IE proprietary attribute but it is from HTML Spec and 
isn't only used for recall IE ActiveX.

I repost here the problem that is that Mozilla Browser Family if find CLSID + 
TYPE + DATA (that can make execution of the object for IE and Mozilla) don't 
parse type and data. 


--cite from Bug 274033 --
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 12

[Boris Zbarsky [:bzbarsky]]

> First: CLSID is not a IE proprietary attribute but it is from HTML Spec and 
> isn't only used for recall IE ActiveX.

"classid" is part of the spec.  Specific classids that start with "clsid" mean
ActiveX controls.  There are classids that Mozilla does recognize (eg ones
starting with "java", which refer to java applet versions).

Comment 13

[Roberto Scano]

(In reply to comment #12)
> > First: CLSID is not a IE proprietary attribute but it is from HTML Spec and 
> > isn't only used for recall IE ActiveX.
> "classid" is part of the spec.  Specific classids that start with "clsid" mean
> ActiveX controls.  There are classids that Mozilla does recognize (eg ones
> starting with "java", which refer to java applet versions).

It's right. But is possible to have a solution like:

if clsid then...
  // check clsid
     if clsid is valid then
       // exec object
     else
       //check if there is type and data
        if type and data = true then
           //exec object
        else
           //not exec object... check for neasted object and/or alternative
        end if
     end if
else
//check if there are type and data
if type and data = true then
   //exec object
else
   //not exec object... check for neasted object and/or alternative
end if

Comment 14

[Boris Zbarsky [:bzbarsky]]

>     if clsid is valid then
>       // exec object
>     else

Doing this else is a spec violation.  If a classid is present, the exact
component identified by that classid must be used to show the content.  Using a
different component that you think does the same thing not only violates the
HTML specification, but can lead to broken behavior (say in case the object data
relies on specific quirks of the exact component it requested).

For example, note that the NPAPI and ActiveX flash plugins (the former usually
used by Mozilla, the latter usually used by IE) are different binaries that
behave differently in many cases.  So if a site explicitly requests that the
ActiveX version of flash be used, using the NPAPI one instead is inappropriate.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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