Bug 70597 – Embed element fails to play ShockWaveFlash content when type attribute is not specified..

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

[Kishore Bolisetty]

Created attachment 111938 [details]
test html to reproduce the issue

OverView : Embed element fails to display ShockWaveFlash content when type attribute is not specified.
Steps to Reproduce : Install ShockWave Flash Plugin and load the attached test html
Actual Result : Shows Missing Plugin / Not able to play content.
Expected Result : If ShockWaveFlash plugin is available, It should play the content.
Useful Info :
1. Reference to spec at http://www.whatwg.org/specs/web-apps/current-work/#attr-embed-src might be useful
2. It is required to find the explicit-content-type from the resource header information /resource itself. (Its just my view)

[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

[Eric Seidel (no email)]

Actually, chrome's issue sounds identical to this one.  I suspect there was some change in WebKIt to cause this regression.

[Eric Seidel (no email)]

Which webkit browser were you testing in?

[Andy Estes]

Why would we expect Flash to load for the attached test case? Flash doesn't register for the file extension .m4v.

[Andy Estes]

(In reply to comment #1)
> 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

FWIW, the flash embed on <http://chrome.plantsvszombies.com/> loads correctly for me in a recent WebKit nightly build. The regression tracked by <http://code.google.com/p/chromium/issues/detail?id=108228> might not affect other ports (or at least not Apple's Mac port).

[Andy Estes]

Oh, despite the file extension ending in .m4v (actually %2Em4v), blip.tv responds with a HTTP 301 redirect to a .swf file. If we followed the redirect as I think the spec tells us to do then we'd end up loading Flash.

[Andy Estes]

I think the behavior we'll see here depends on what WebKit port you test in. Testing on the Mac, I see that we don't match %2Em4v to the .m4v extension registered by QuickTime. That sounds like a URL sanitization bug on our part. But since we don't match the extension, we go down the subframe loading path and end up loading a plugin document in the subframe.

Chrome 15 appears to correctly sanitize the URL and it loads the QuickTime plug-in. On systems that don't have QuickTime installed, I'm not surprised that a missing plug-in indicator is shown.

[Eric Seidel (no email)]

The URL handling is a difference between KURL and GURL. :(

[Eric Seidel (no email)]

(In reply to comment #5)
> (In reply to comment #1)
> > 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
> 
> FWIW, the flash embed on <http://chrome.plantsvszombies.com/> loads correctly for me in a recent WebKit nightly build. The regression tracked by <http://code.google.com/p/chromium/issues/detail?id=108228> might not affect other ports (or at least not Apple's Mac port).

Are you aware of any changes to WebCore that could have caused us to start passing a null/empty mimetype  up to the WebKit layer (via the FrameLoaderClient::createPlugin callback)?

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