Red square covers Acid3 test in Safari http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html I'm not even entirely sure what the red square is. I think it's the <map>. The inspector wasn't very helpful due to bug 16755.
I will note that neither Opera or FF display the red square.
FYI the red square is from the <object> element, which has this CSS: object { position: fixed; left: 130.5px; top: 84.3px; background: transparent; } /* show objects if they have content */ Hixie made a comment in IRC about this begin a test of <object> Content-Type support. Looking at the sent headers: curl -I "http://www.hixie.ch/tests/evil/acid/003/support-a.png" HTTP/1.1 404 Not Found Date: Sun, 06 Jan 2008 08:29:39 GMT Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 Last-Modified: Thu, 01 Jun 2006 06:09:43 GMT ETag: "13bef5e-908-839d37c0" Accept-Ranges: bytes Content-Length: 2312 X-Pingback: http://tracking.damowmow.com/ Content-Language: en-GB-x-Hixie Content-Type: image/png I guess the issue there is the 404 which we're not respecting?
One could argue that the 404 response itself should be fixed. For instance, why would a server claim there is no representation (404) and then include an ETag???
So this is the test in question: function () { // test 16: <object> handling and HTTP status codes var oC = document.createElement('object'); oC.appendChild(document.createTextNode("FAIL")); var oB = document.createElement('object'); var oA = document.createElement('object'); oA.data = "support-a.png"; oB.data = "support-b.png"; oB.appendChild(oC); oC.data = "support-c.png"; oA.appendChild(oB); document.getElementsByTagName("map")[0].appendChild(oA); // assuming the above didn't raise any exceptions, this test has passed // (the real test is whether the rendering is correct) return 1; }, http://www.hixie.ch/tests/evil/acid/003/support-a.png // gives a 404 http://www.hixie.ch/tests/evil/acid/003/support-b.png // returns wrong content type http://www.hixie.ch/tests/evil/acid/003/support-c.png // returns identical to a, (including Etag), but but returns 200 instead of 404.
This is at least related to bug 15242, possibly even dependent on. It wasn't clear to me from my brief trip through the FrameLoader code over the weekend, how we recognize 404s down in WebCore.
If we're to implement this the way Mark started to, then we'll need to add a new callback to CachedResourceClient. It could even be as specific as respondedWithError() or similar. Hooking into the notifyFinished() callback would be too late, since who knows, the 404 page could be 10mb and there is no need to download the whole page only to trip over into <object> fallback (or ignore the CachedStyleSheet)
Created attachment 18724 [details] Minimal test case
We do respect 404s on object fallback. That was required for Acid2. I think the issue is with the middle PNG (the one with the wrong content type). I'm not sure what's going on though.
I don't understand what is wrong with support-c.png. I also don't understand why support-b.png would not be used. Shouldn't it be used?
Aha, I get it. support-b.png should be honored as text/html (and thus render nothing). This test is exposing the problems with not honoring the true content type of the data.
Created attachment 18927 [details] Standalone test case from Acid 3 suite
Created attachment 18928 [details] Static test case from Acid3 suite
Created attachment 18929 [details] test case with all 3 cases separated
Dave, based on "test case with all 3 cases separated" it's clear that Webkit has a problem only with support-a.png and support-b.png. support-c.png is correct, and should be displayed, but in Acid3 this picture is covered by "blank" support-b.png.
Created attachment 18931 [details] test case with all 3 cases separated some issues in test case corrected.
Created attachment 18935 [details] test for treating text/html file as CSS file Another test from Acid3 (a word Acid3 should not be red). It shows that Webkit treats text/html file as text/css and incorrectly applies styles from it to current document.
I wonder if the last test case should be filed on separate bug report? However the main problem relies on incorrectly handling MIME types and HTTP status codes.
*** Bug 16690 has been marked as a duplicate of this bug. ***
Another variant of the issue: http://biesi.damowmow.com/object/011.html
Many various tests for <object> MIME type handling are available on: http://biesi.damowmow.com/object/
Fixed in r30438.