Bug 44933 – When a plug-in is loaded by an <object> element that does not specify a type attribute, the correct parameters are not passed to the plug-in.

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Plug-ins

[Andy Estes]

Take the following snippet:

<object width="480" height="385">
    <param name="movie" value="http://www.youtube.com/v/oHg5SJYRHA0?fs=1&amp;hl=en_US"></param>
    <param name="allowFullScreen" value="true"></param>
    <param name="allowscriptaccess" value="always"></param>
</object>

Safari will determine the MIME type of the resource from the Content-Type header and load the appropriate plug-in, but it will not pass the 'allowFullScreen' and 'allowscriptaccess' parameters to the plug-in. If type="application/x-shockwave-flash" is added as an attribute to the <object> element, the correct parameters will be passed to the plug-in.

[Andy Estes]

<rdar://problem/8375816>

[Andy Estes]

If WebKit can't determine the resource's MIME type up front, it will try to load the resource in a subframe, creating an appropriate child document based on the Content-Type in the response. In the case of a plug-in, a dummy document will be created with an <embed> loading the plug-in with a few hard-coded attributes (width, height, src and type). However, the attributes specified on the <object> that loaded the subframe are not copied down to the <embed>, nor are any of the <param> elements passed to the plug-in.

I don't think creating a subframe is the right thing to do in this case. HTML5 says that if no data or type attribute is specified on the <object>, fallback content should be rendered. Since the URL in the above snippet is specified in a <param> rather than an attribute, the right thing to do here is to render fallback.

Since WebKit has supported specifying a resource's URL or MIME type in a <param> element for quite a while, I think it should continue to do so, but under a more limited set of circumstances. Specifically, if WebKit can determine that a resource will load a plug-in up front by consulting a <param> named 'type' or the file extension in a <param> named "src", "movie", "code" or "url", it should use that URL and MIME type to load the plug-in directly (without creating a subframe). If it can't determine the resource's type, or the resource's type is not a plug-in, and the object has no data or type attribute, fallback content should be rendered.

The rules for what happens when data or type are specified on the <object> should continue to apply.

[Adam Barth]

This seems related to this bug:
http://code.google.com/p/chromium/issues/detail?id=55954

[Adam Barth]

What's the planned resolution for this issue?  It seems like we've put ourselves in a bit of a pickle here.

[Andy Estes]

(In reply to comment #4)
> What's the planned resolution for this issue?  It seems like we've put ourselves in a bit of a pickle here.

I don't think the chromium bug has it quite right. This was actually caused by r66156 and resolved by r66992. Chromium hasn't merged that change due to a performance regression which is tracked by https://bugs.webkit.org/show_bug.cgi?id=45524. The resolution is to fix the regression.

[Alexey Proskuryakov]

Mass closing plug-in bugs, as plug-in support has been removed from WebKit.

Please comment and/or reopen if this still affects WebKit in some way.