235053 - [FIXr]Flash objects don't work if type attribute is specified

Status: RESOLVED FIXED

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

Description

[Rick Bull]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219

I've found since about 1.3/1.4 time (I think) that flash applets that use the
<object> tag with the data and type attributes don't work. My code works fine in
all other browsers I've tested (IE, Opera, Konqueror) under both Linux and
Windows, and also used to work fine in older versions of Mozilla. I've played
about with the code, removing classid, adding archive, etc. The only way I've
found to get the applet to load is to remove the type attribute, which causes IE
to fail.

If I load the SWF file directly to Mozilla it works fine, so I know it's not a
lack of Flash that's the problem. Could Mozilla be seeing the data type and
thinking that it doesn't support it or something?

Also if I don't specify the classid attribute (as a list apart recommends I
think) Mozilla won't display the alternate text inside the <object> element,
which I'm pretty sure it wrong - it should display it whatever.

Reproducible: Always
Steps to Reproduce:
1. Load URI specified above
Actual Results:  
See that flash applet doesn't load, instead you see the alternate text

Expected Results:  
Applet should have loaded instead of alternate text.

Comment 1

[Bill Mason]

Bug 96976 covers Mozilla not displaying alternate content for an OBJECT tag.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Well, there's a whole bunch of issues here:

1)  If you have the classid attribute set, the browser is only allowed to show
    the <object> if it has the exact component that classid points to.  You're
    pointing to an ActiveX classid, and Mozilla does not do ActiveX plugins, so
    we render the alternate content.  This is correct.  Some other browsers
    don't do this and just guess what to render in based on the type when
    classid is set, but that's very broken in many cases and has some serious
    security implications if nothing else.

2)  If you remove the classid, we don't render the alternate content because we
    _are_ rendering the plugin.  Unfortunately, it has a height of "100%", which
    computes to "auto" because the height of the parent is auto and the page is
    in standards mode.  Auto height for an <object> computes to 0, since there
    is no way to get the intrinsic size.  Simply removing the doctype or
    changing to one that triggers quirks mode will fix this issue.  Otherwise,
    setting height:100% on all ancestors of the <object> will.  This behavior is
    also correct.

3)  If there is no type attribute, we instantiate an iframe there and load flash
    document into the iframe!  For an iframe, auto height is 240x200 or
    something along those lines.  Further, inside the iframe we're just getting
    the raw data stream, so there is no classid and we render it.

#3 is definitely a bug.  It's caused by bug 200568 being fixed incompletely. 
Attaching a patch for this issue.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix for the missing type issue

Comment 4

[Rick Bull]

Just a quick note to say I've removed the classid attribute from the test page
as per Boris' comments. Hope that's alright.

>For an iframe, auto height is 240x200 or something along those lines.
Yeah that would seem about right, as when I removed the type attribute it showed
a small flash applet, which I thought was weird, but it makes sense now.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 141975 [details] [diff] [review]
Fix for the missing type issue

+    CopyASCIItoUTF16(contentType, type);
   }
+    
+  nsXPIDLCString value;
+  NS_ConvertUCS2toUTF8 typeStr(type);

that seems most stupid to me.
why not use an nsCAutoString for the type and convert only if type had a value?

+  rv = catman->GetCategoryEntry("Gecko-Content-Viewers",typeStr.get(),
getter_Copies(value));
add a space before typeStr.get()

So the actual fix is that we do the Equals with the plugin dlf contractid also
in the data= attribute case?


r=biesi

Comment 6

[Boris Zbarsky [:bzbarsky]]

> why not use an nsCAutoString for the type and convert only if type had a value?

Will do.

> So the actual fix is that we do the Equals with the plugin dlf contractid also
> in the data= attribute case?

Yep.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Fix checked in for the "no type set" issue.  It won't fix the site in question
on it's own, due to issues #1 and #2 in comment 2.  But those are not issues
with Mozilla...