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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=68789





--- Comment #22 from Andy Estes <aestes at apple.com>  2011-10-13 12:13:31 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.