Bug 16760 – Incorrect handling of <object> data MIME types (affects Acid3)

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

I will note that neither Opera or FF display the red square.

[Eric Seidel (no email)]

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?

[Julian Reschke]

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???

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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)

[Robert Blaut]

Created attachment 18724 [details]
Minimal test case

[Dave Hyatt]

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.

[Dave Hyatt]

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?

[Dave Hyatt]

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.

[Robert Blaut]

Created attachment 18927 [details]
Standalone test case from Acid 3 suite

[Robert Blaut]

Created attachment 18928 [details]
Static test case from Acid3 suite

[Robert Blaut]

Created attachment 18929 [details]
test case with all 3 cases separated

[Robert Blaut]

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.

[Robert Blaut]

Created attachment 18931 [details]
test case with all 3 cases separated

some issues in test case corrected.

[Robert Blaut]

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.

[Robert Blaut]

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.

[Robert Blaut]

*** Bug 16690 has been marked as a duplicate of this bug. ***

[Robert Blaut]

Another variant of the issue: http://biesi.damowmow.com/object/011.html

[Robert Blaut]

Many various tests for <object> MIME type handling are available on: http://biesi.damowmow.com/object/

[Dave Hyatt]

Fixed in r30438.