Consider a web page with the following markup: <!DOCTYPE html> <html> <body> <object data="resources/image.php"></object> </body> </html> where image.php is a script that returns image data with an appropriate Content-Type HTTP header. In WebKit2, no image is display when this page is viewed. In WebKit1, Firefox for Mac 45.0.1 and Google Chrome for Mac 50.0.2661.75 beta (64-bit), an image is displayed when the page is viewed. Suppose the image.php returns Content-Type image/jpeg and consider a web page with the following markup: <!DOCTYPE html> <html> <body> <object data="resources/image.php" type="image/jpeg"></object> </body> </html> In WebKit2, an image is displayed when this page is viewed.
Created attachment 276450 [details] Layout Test DumpRenderTree/WebKitTestRunner-compatible layout test
Comment on attachment 276450 [details] Layout Test Attachment 276450 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/1163983 New failing tests: http/tests/misc/object-without-type-load-php-image.html
Created attachment 276478 [details] Archive of layout-test-results from ews107 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 276450 [details] Layout Test Attachment 276450 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/1163984 New failing tests: http/tests/misc/object-without-type-load-php-image.html
Created attachment 276479 [details] Archive of layout-test-results from ews123 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews123 Port: ios-simulator-wk2 Platform: Mac OS X 10.10.5
Note that http/tests/security/contentSecurityPolicy/embed-redirect-blocked3.htm and http/tests/security/contentSecurityPolicy/object-redirect-blocked3.htm are both already passing on GTK (WK2).
This is because in WebKit1 WebFrameLoaderClient::objectContentType returns ObjectContentType::Frame for php mime type: if ([m_webFrame->_private->webFrameView _viewClassForMIMEType:type]) return ObjectContentType::Frame; I guess _viewClassForMIMEType has a different behavior than MIMETypeRegistry::isSupportedNonImageMIMEType().
Maybe we should just claim to support php, assuming the server will deal with it?