70597 2011-10-21 04:19:10 -0700 Embed element fails to play ShockWaveFlash content when type attribute is not specified.. 2022-07-01 11:35:06 -0700 1 1 1 Unclassified WebKit Plug-ins 528+ (Nightly build) Unspecified Unspecified RESOLVED WONTFIX P1 Normal --- 0 kbolisetty webkit-unassigned aestes andersca ap ddkilzer eric mrahaman sam oldest_to_newest 488304 0 111938 kbolisetty 2011-10-21 04:19:10 -0700 Created attachment 111938 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) 525795 1 eric 2011-12-21 16:21:26 -0800 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 525798 2 eric 2011-12-21 16:21:51 -0800 Actually, chrome's issue sounds identical to this one. I suspect there was some change in WebKIt to cause this regression. 525817 3 eric 2011-12-21 16:30:27 -0800 Which webkit browser were you testing in? 525857 4 aestes 2011-12-21 17:15:20 -0800 Why would we expect Flash to load for the attached test case? Flash doesn't register for the file extension .m4v. 525865 5 aestes 2011-12-21 17:20:12 -0800 (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). 525876 6 aestes 2011-12-21 17:28:35 -0800 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. 525881 7 aestes 2011-12-21 17:34:41 -0800 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. 525917 8 eric 2011-12-21 18:39:50 -0800 The URL handling is a difference between KURL and GURL. :( 525918 9 eric 2011-12-21 18:40:58 -0800 (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)? 1879870 10 ap 2022-07-01 11:35:06 -0700 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. 111938 2011-10-21 04:19:10 -0700 2011-10-21 04:19:10 -0700 test html to reproduce the issue test.html text/html 59 kbolisetty PGVtYmVkIHNyYz0iaHR0cDovL2JsaXAudHYvcGxheS9sbDZDaFpFdEFBJTJFbTR2IiA+PC9lbWJl ZD4=