Bug 68789 – Unable to embed a flash plug-in using an <embed> element with mime type "application/octet-stream"

• Component: Plug-ins
• Status: RESOLVED WONTFIX

[Swapna P]

Created attachment 108627 [details]
Test case

step:
Load the HTML page provided.

Issue:
It is showing message as "Missing Plug-in" instead of playing flash.
If we replace mime type  "application/octet-stream" with "application/x-shockwave-flash" in the test case, its able to play the flash. This is valid mime-type for *.swf content.

Other browsers:
FF 6.0.2:  ok
IE 7.0:  ok
Google Chrome: ok

[Andy Estes]

I'm not sure why the test case is a .rar file with a 'text/html' MIME type.

[Andy Estes]

Created attachment 108711 [details]
Working test case

This test case loads a .swf from adobe.com but specifies the MIME type as 'application/octet-stream'. I verified that Firefox and Chrome will load the Flash plug-in but Safari will display the missing plug-in indicator.

[Anders Carlsson]

(In reply to comment #2)
> Created an attachment (id=108711) [details]
> Working test case
> 
> This test case loads a .swf from adobe.com but specifies the MIME type as 'application/octet-stream'. I verified that Firefox and Chrome will load the Flash plug-in but Safari will display the missing plug-in indicator.

Both in WK1 and WK2? What if you use another unknown MIME type?

[Andy Estes]

(In reply to comment #3)
> Both in WK1 and WK2? 

Yes

>What if you use another unknown MIME type?

I changed the MIME type to 'invalid'. Firefox continues to load the plug-in, likely due to the .swf file extension. Chrome on the other hand starts displaying the missing plug-in indicator, so it appears to give special meaning to 'application/octet-stream'.

[Anders Carlsson]

(In reply to comment #4)
> (In reply to comment #3)
> > Both in WK1 and WK2? 
> 
> Yes
> 
> >What if you use another unknown MIME type?
> 
> I changed the MIME type to 'invalid'. Firefox continues to load the plug-in, likely due to the .swf file extension. Chrome on the other hand starts displaying the missing plug-in indicator, so it appears to give special meaning to 'application/octet-stream'.

In PluginInfoStore::findPlugin in WebKit2, we are supposed to fall back to the file extension if no plug-in claims to handle the MIME type. However, we currently only do that if there is no MIME type specified!

Something like:

Index: UIProcess/Plugins/PluginInfoStore.cpp
===================================================================
--- UIProcess/Plugins/PluginInfoStore.cpp	(revision 95980)
+++ UIProcess/Plugins/PluginInfoStore.cpp	(working copy)
@@ -193,7 +193,7 @@
 
     // Next, check if any plug-ins claim to support the URL extension.
     String extension = pathExtension(url).lower();
-    if (!extension.isNull() && mimeType.isEmpty()) {
+    if (!extension.isNull()) {
         PluginModuleInfo plugin = findPluginForExtension(extension, mimeType);
         if (!plugin.path.isNull())
             return plugin;

should probably fix the bug. Not sure if the HTML5 spec clarifies any of this...

[Kishore Bolisetty]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Both in WK1 and WK2? 
> > 
> > Yes
> > 
> > >What if you use another unknown MIME type?
> > 
> > I changed the MIME type to 'invalid'. Firefox continues to load the plug-in, likely due to the .swf file extension. Chrome on the other hand starts displaying the missing plug-in indicator, so it appears to give special meaning to 'application/octet-stream'.
> 
> In PluginInfoStore::findPlugin in WebKit2, we are supposed to fall back to the file extension if no plug-in claims to handle the MIME type. However, we currently only do that if there is no MIME type specified!
> 
> Something like:
> 
> Index: UIProcess/Plugins/PluginInfoStore.cpp
> ===================================================================
> --- UIProcess/Plugins/PluginInfoStore.cpp    (revision 95980)
> +++ UIProcess/Plugins/PluginInfoStore.cpp    (working copy)
> @@ -193,7 +193,7 @@
> 
>      // Next, check if any plug-ins claim to support the URL extension.
>      String extension = pathExtension(url).lower();
> -    if (!extension.isNull() && mimeType.isEmpty()) {
> +    if (!extension.isNull()) {
>          PluginModuleInfo plugin = findPluginForExtension(extension, mimeType);
>          if (!plugin.path.isNull())
>              return plugin;
> 
> should probably fix the bug. Not sure if the HTML5 spec clarifies any of this...

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Both in WK1 and WK2? 
> > 
> > Yes
> > 
> > >What if you use another unknown MIME type?
> > 
> > I changed the MIME type to 'invalid'. Firefox continues to load the plug-in, likely due to the .swf file extension. Chrome on the other hand starts displaying the missing plug-in indicator, so it appears to give special meaning to 'application/octet-stream'.
> 
> In PluginInfoStore::findPlugin in WebKit2, we are supposed to fall back to the file extension if no plug-in claims to handle the MIME type. However, we currently only do that if there is no MIME type specified!
> 
> Something like:
> 
> Index: UIProcess/Plugins/PluginInfoStore.cpp
> ===================================================================
> --- UIProcess/Plugins/PluginInfoStore.cpp    (revision 95980)
> +++ UIProcess/Plugins/PluginInfoStore.cpp    (working copy)
> @@ -193,7 +193,7 @@
> 
>      // Next, check if any plug-ins claim to support the URL extension.
>      String extension = pathExtension(url).lower();
> -    if (!extension.isNull() && mimeType.isEmpty()) {
> +    if (!extension.isNull()) {
>          PluginModuleInfo plugin = findPluginForExtension(extension, mimeType);
>          if (!plugin.path.isNull())
>              return plugin;
> 
> should probably fix the bug. Not sure if the HTML5 spec clarifies any of this...


Though HTML5 doesn’t talks about plugin support or implementation, it is redirects to Gecko Plugin API reference http://dev.w3.org/html5/spec/Overview.html#refsNPAPI & https://developer.mozilla.org/en/Gecko_Plugin_API_Reference .
I could find the below statement from https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Basics#Plug-in_display_modes
“A full-page plug-in is a visible plug-in that is not part of an HTML page. The server looks for the media (MIME) type registered by a plug-in, based on the file extension, and starts sending the file to the browser.”
So It’s not a bad idea to fall back to file extension if no plugin claims to handle the specified mimetype.

[Kishore Bolisetty]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Both in WK1 and WK2? 
> > 
> > Yes
> > 
> > >What if you use another unknown MIME type?
> > 
> > I changed the MIME type to 'invalid'. Firefox continues to load the plug-in, likely due to the .swf file extension. Chrome on the other hand starts displaying the missing plug-in indicator, so it appears to give special meaning to 'application/octet-stream'.
> 
> In PluginInfoStore::findPlugin in WebKit2, we are supposed to fall back to the file extension if no plug-in claims to handle the MIME type. However, we currently only do that if there is no MIME type specified!
> 
> Something like:
> 
> Index: UIProcess/Plugins/PluginInfoStore.cpp
> ===================================================================
> --- UIProcess/Plugins/PluginInfoStore.cpp    (revision 95980)
> +++ UIProcess/Plugins/PluginInfoStore.cpp    (working copy)
> @@ -193,7 +193,7 @@
> 
>      // Next, check if any plug-ins claim to support the URL extension.
>      String extension = pathExtension(url).lower();
> -    if (!extension.isNull() && mimeType.isEmpty()) {
> +    if (!extension.isNull()) {
>          PluginModuleInfo plugin = findPluginForExtension(extension, mimeType);
>          if (!plugin.path.isNull())
>              return plugin;
> 
> should probably fix the bug. Not sure if the HTML5 spec clarifies any of this...

We found the above working on WebKit2 when used MiniBrowser,
But it doesnt works for me on WebKit with winlauncher.
The following code change is required on WebKit with winlauncher/safari.
$ svn diff PluginDatabase.cpp
Index: PluginDatabase.cpp
===================================================================
--- PluginDatabase.cpp  (revision 95938)
+++ PluginDatabase.cpp  (working copy)
@@ -279,8 +279,11 @@

 PluginPackage* PluginDatabase::findPlugin(const KURL& url, String& mimeType)
 {
+       PluginPackage* plugin = NULL;
     if (!mimeType.isEmpty())
-        return pluginForMIMEType(mimeType);
+                       plugin = pluginForMIMEType(mimeType);
+       if(plugin)
+        return plugin;

     String filename = url.lastPathComponent();
     if (filename.endsWith("/"))
@@ -291,7 +294,7 @@
         return 0;

     String mimeTypeForExtension = MIMETypeForExtension(filename.substring(exten
sionPos + 1));
-    PluginPackage* plugin = pluginForMIMEType(mimeTypeForExtension);
+    plugin = pluginForMIMEType(mimeTypeForExtension);
     if (!plugin) {
         // FIXME: if no plugin could be found, query Windows for the mime type
         // corresponding to the extension.

kbolisetty@IM-LP-093 ~/WebKit/Source/WebCore/plugins

Can some one suggest if changes needs to be done at both the places?

[Ian 'Hixie' Hickson]

This is covered in detail in the spec.

For <object>, start reading here:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#attr-object-name

For <embed>, start reading here:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#attr-embed-src

For full-page plugins, start reading here:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#navigate
http://www.whatwg.org/specs/web-apps/current-work/complete.html#read-plugin

[Andy Estes]

From Section 4.8.3:

"The type attribute, if present, gives the MIME type by which the plugin to instantiate is selected. The value must be a valid MIME type. If both the type attribute and the src attribute are present, then the type attribute must specify the same type as the explicit Content-Type metadata of the resource given by the src attribute."

This indicates that Safari is correct (per the spec) in not loading a plug-in for the test case, since the .swf resource has a Content-Type of 'application/x-shockwave-flash' which doesn't match the specified type attribute.

[Andy Estes]

I'm updating the title to reflect that this bug is specifically about embedding a plug-in via <embed>. I'm not saying that there is not an issue with <object>, but since the rules for <object> are different and more complicated, it'd be clearer to discuss that in a separate bug report.

[Adam Roben (:aroben)]

(In reply to comment #9)
> This indicates that Safari is correct (per the spec) in not loading a plug-in for the test case, since the .swf resource has a Content-Type of 'application/x-shockwave-flash' which doesn't match the specified type attribute.

It is interesting that the spec doesn't agree with Firefox, IE, and Chrome's behavior.

[Kishore Bolisetty]

(In reply to comment #11)
> (In reply to comment #9)
> > This indicates that Safari is correct (per the spec) in not loading a plug-in for the test case, since the .swf resource has a Content-Type of 'application/x-shockwave-flash' which doesn't match the specified type attribute.
> 
> It is interesting that the spec doesn't agree with Firefox, IE, and Chrome's behavior.

I am not sure, If my interpretation of the spec is correct, but I understood it like this.. When both src & type attributes are present, if type attribute specified is not supported by the plugin, then src's content type can be used to check if the plugin can handle it. src content type can determined by its extension, though the ideal mechanism to consider is the Header response from http transaction if the src url is a http.
These are the lines from the spec, that made me to arrive at the above conclusion. Please correct me if I am wrong.
====================Text from the spec=======================
Point 1:
If the element has a src attribute set

    The user agent must resolve the value of the element's src attribute, relative to the element. If that is successful, the user agent should fetch the resulting absolute URL, from the element's browsing context scope origin if it has one. The task that is queued by the networking task source once the resource has been fetched must find and instantiate an appropriate plugin based on the content's type, and hand that plugin the content of the resource, replacing any previously instantiated plugin for the element.

    Fetching the resource must delay the load event of the element's document.
Point 2:
The type of the content being embedded is defined as follows:

    If the element has a type attribute, and that attribute's value is a type that a plugin supports, then the value of the type attribute is the content's type.

    Otherwise, if the <path> component of the URL of the specified resource (after any redirects) matches a pattern that a plugin supports, then the content's type is the type that that plugin can handle.

    For example, a plugin might say that it can handle resources with <path> components that end with the four character string ".swf".

    Otherwise, if the specified resource has explicit Content-Type metadata, then that is the content's type.

    Otherwise, the content has no type and there can be no appropriate plugin for it.
==============================End================================

[Andy Estes]

(In reply to comment #12)
> I am not sure, If my interpretation of the spec is correct, but I understood it like this.. When both src & type attributes are present, if type attribute specified is not supported by the plugin, then src's content type can be used to check if the plugin can handle it. src content type can determined by its extension, though the ideal mechanism to consider is the Header response from http transaction if the src url is a http.

I read the spec to say that file extension should be preferred to the Content-Type header, but this sounds right otherwise. I think I mistakenly quoted a requirement for authors rather than implementors earlier.

[Kishore Bolisetty]

(In reply to comment #13)
> (In reply to comment #12)
> > I am not sure, If my interpretation of the spec is correct, but I understood it like this.. When both src & type attributes are present, if type attribute specified is not supported by the plugin, then src's content type can be used to check if the plugin can handle it. src content type can determined by its extension, though the ideal mechanism to consider is the Header response from http transaction if the src url is a http.
> 
> I read the spec to say that file extension should be preferred to the Content-Type header, but this sounds right otherwise. I think I mistakenly quoted a requirement for authors rather than implementors earlier.

Thanks for the clarification. To take it even more forward, this issue is present on WebKit and WebKit2. Also the patches were proposed for both in [Comment #5 From Anders Carlsson & Comment #7 From KishoreGanesh ].Is it ok to combine these and submit as a single patch for review Or Shall I raise another bug for webkit2 and submit the patch?

[Andy Estes]

(In reply to comment #14)
> Is it ok to combine these and submit as a single patch for review

Absolutely.

[Kishore Bolisetty]

Created attachment 109277 [details]
patch to use src extension when no plugin is available for mimetype

Using src url extension when there is no plugin to handle specified mimetype in type attribute of embed element.

[Anders Carlsson]

Comment on attachment 109277 [details]
patch to use src extension when no plugin is available for mimetype

It seems to me like it would be possible to write a test for this!

[Kishore Bolisetty]

(In reply to comment #17)
> (From update of attachment 109277 [details])
> It seems to me like it would be possible to write a test for this!

I missed out that part, I will soon analyze and provide the test case along with the patch.

[Kishore Bolisetty]

Created attachment 110880 [details]
LayoutTest html

Attached the test HTML that can be added in LayoutTests.

[Andy Estes]

Comment on attachment 109277 [details]
patch to use src extension when no plugin is available for mimetype

I'm going to r- this obsolete patch so you can upload a new one that contains your layout test.

[Kishore Bolisetty]

(In reply to comment #20)
> (From update of attachment 109277 [details])
> I'm going to r- this obsolete patch so you can upload a new one that contains your layout test.

Hi All,
I just found a similar test case already present in LayoutTests.
......LayoutTests/plugins/invalid-mime-with-valid-extension-shows-missing-plugin.html
I think adding a new test case would be redundant if the above test can suffice the need. Can some one please confirm the same ?

One more observation : chromium-linux is not using the WebCore/Plugins or WebKit2/Plugins implementation. Looks like it has got its own plugin code base in Source/WebKit/chromium/webkit/plugins/* . Thats why the test must be passing in chromium but the bug remains in other ports of WebKit/WebKit2.

Please correct me if i make any wrong assumptions.
Thanks.

[Andy Estes]

(In reply to comment #21)
> (In reply to comment #20)
> > (From update of attachment 109277 [details] [details])
> > I'm going to r- this obsolete patch so you can upload a new one that contains your layout test.
> 
> Hi All,
> I just found a similar test case already present in LayoutTests.
> ......LayoutTests/plugins/invalid-mime-with-valid-extension-shows-missing-plugin.html

Ah, I'm glad you pointed out that test; it reminded me of the motivation for our current behavior. Consider the following markup:

<embed type="application/x-shockwave-flash" src="movie.mp4">

If you have Flash installed, then it's obviously correct to instantiate the Flash plug-in, but what if Flash isn't installed, but another plug-in that claims to support .mp4 files (e.g. QuickTime) is installed? Is it correct to load the resource in QuickTime even though the author explicitly stated the MIME type as 'application/x-shockwave-flash'? What if the .mp4 file uses a container format that Flash supports but QuickTime doesn't? In this case it'd be more correct to show the 'Missing Plug-In' indicator than try to load a file into a different plug-in than the author specified.

In this specific bug, we're talking about 'application/octet-stream', which is a generic MIME type for binary data. For that specific MIME type, I think it's probably okay to treat that as equivalent to 'no MIME type' and consult the file extension, but I don't think it's right to ignore a arbitrary specified MIME type and use the file extension instead.

[Andy Estes]

Here is the specific example that motivated our current behavior (from <http://thewoodwhisperer.com/halloween-router-bowl/>):

<embed src="http://blip.tv/play/ll6ChZEtAA%2Em4v" type="application/x-shockwave-flash" width="550" height="340" allowscriptaccess="always" allowfullscreen="true"></embed>

If Flash isn't installed, we would check for plug-ins that support .m4v files (%2E is the percent-encoding of '.'). QuickTime claims to support .m4v files, but can't handle this particular file's container format. It seemed logical at the time to not load a plug-in that claims to support a particular file extension but *not* the specified MIME type, although I now think that's what HTML5 says we should do.

I tested this in Firefox with Flash disabled and it also displays a missing plug-in indicator rather than loading QuickTime, but I think that's because it doesn't convert %2E to '.' before comparing the file extension to it's plug-in database. If I change the %2E to a '.' it does in fact load QuickTime when Flash is disabled.

My conclusion is that the approach we're taking in this bug is the right one. I'd like to not re-introduce the bug with blip.tv embeds when Flash is disabled, but I think the better way to go about that is to figure out why our behavior differs from Firefox when file extensions contain percent-encodings.

[Kishore Bolisetty]

I am presenting my observations tried with different combinations of src attribute and type attribute for an embed element.

What Spec Says: (http://www.whatwg.org/specs/web-apps/current-work/#attr-embed-src)
==================
only type 	=> Mimetype of the resource that is being loaded
only src  	=> Url of Resource to be loaded.
both type & src => type must be equal to explicit-content-type of the resource.

What FireFox Implemented:
===========================
only type 	=> use the Mimetype, if found dont show missing plugin, if not found show missing plugin.
only src  	=> No matter what extension is, It tries to download and gets explicit-content-mimetype.
		   Displays the content if it has any supporting plugin.
		   If source is Present, It will never show Missing Plugin.
		   It is will either display content / Error Message / Blank Page
both type & src	=> It gets the explicit mimetype from the source.
		   If the specified type is not found and explicit-content-mimetype is supported, It will just display the content.
		   If the specified type is found, explicit-content-mimetype is not matching with the specified type, It will throw an error. 
		   It will not display the content even though it is capable of doing that.

What Safari Does:
=================================
only type 	 => use the Mimetype, if found dont show missing plugin, if not found show missing plugin.
only src	=> Finds the plugin based on src url extension if present.
		   If no supporting plugin is found, Missing Plugin is displayed.
		   If supporting plugin is found, but explict-content-mime is not supported, Cant display content.
both type & src	=> same as "only type"

[Andy Estes]

Thanks for this analysis!

I'd encourage you to proceed by including a test case (or new results for an existing test case) in your patch and posting it for review. If your analysis shows there are other compatibility bugs, you should file those separately.

[Andy Estes]

Another question: are you aware of any websites affected by this issue, or did you bring this up for spec compliance reasons?

[Kishore Bolisetty]

Created attachment 111913 [details]
patch to use src extension when no plugin is available for mimetype

patch to use src extension when no plugin is available for mimetype

[Kishore Bolisetty]

(In reply to comment #26)
> Another question: are you aware of any websites affected by this issue, or did you bring this up for spec compliance reasons?

We found this Issue, while trying to fix Bug: 21649 
https://bugs.webkit.org/show_bug.cgi?id=21649

[Kishore Bolisetty]

(In reply to comment #25)
> Thanks for this analysis!
> 
> I'd encourage you to proceed by including a test case (or new results for an existing test case) in your patch and posting it for review. If your analysis shows there are other compatibility bugs, you should file those separately.

As per your suggestion, I submitted the patch to this bug and create a new bug poped up during our discussions here.
Please find the bug logged @ https://bugs.webkit.org/show_bug.cgi?id=70597
I suppose, solving this bugs will help us in aligning with spec aswell Firefox & Opera behaviour.
Thanks.

[Andy Estes]

Comment on attachment 111913 [details]
patch to use src extension when no plugin is available for mimetype

View in context: https://bugs.webkit.org/attachment.cgi?id=111913&action=review

Not all ports go through one of the two code paths you modified. For instance, I believe WebKit1 on the Mac will still show the missing plug-in indicator after this patch. r- because of that. I have other comments below.

> Source/WebCore/ChangeLog:3
> +        Bug 68789: Using src url extension when there is no plugin to handle specified mimetype in type attribute of embed element.

I'd just use the bug title here.

> Source/WebCore/ChangeLog:11
> +        (WebCore::PluginDatabase::findPlugin):Modifed to make use of src extension to find matching plugin when no plugin is found for specified mime type.

There should be a space between the colon and the word modified. You also misspelled modified.

> Source/WebKit2/ChangeLog:3
> +        Bug 68789: Using src url extension when there is no plugin to handle specified mimetype in type attribute of embed element.

I'd just use the bug title here.

> LayoutTests/ChangeLog:9
> +        * plugins/invalid-mime-with-valid-extension-shows-missing-plugin.html: Test should pass if the plugin is resolved based on extension.

This test is now incorrectly named based on what we expect it to do.

> LayoutTests/ChangeLog:11
> +        * plugins/unsupportedmime-supportedextension.html: Added.

How is this test different than the one above? They both seem to verify that a plug-in loads, just using different TestNetscapePlugIn mechanisms.

[Eric Seidel (no email)]

Chrome just had to work around a (possibly) related issue, where a null mimeType is being passed up to the WebKit layer from SubresourceLoader/HTMLEmbedElement.
http://code.google.com/p/chromium/issues/detail?id=108228

[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.