Bug 44933
| Summary: | 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. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Andy Estes <aestes> |
| Component: | Plug-ins | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | abarth, aestes, ap |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | OS X 10.5 | ||
Andy Estes
Take the following snippet:
<object width="480" height="385">
<param name="movie" value="http://www.youtube.com/v/oHg5SJYRHA0?fs=1&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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.