[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 #23 from Andy Estes <aestes at apple.com>  2011-10-14 11:53:24 PST ---
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.

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