Bug 16760 - Incorrect handling of <object> data MIME types (affects Acid3)
Summary: Incorrect handling of <object> data MIME types (affects Acid3)
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://acid3.acidtests.org/
Keywords: HasReduction
: 16690 (view as bug list)
Depends on:
Blocks: Acid3
  Show dependency treegraph
Reported: 2008-01-05 19:17 PST by Eric Seidel (no email)
Modified: 2008-02-20 18:00 PST (History)
4 users (show)

See Also:

Minimal test case (315 bytes, text/html)
2008-01-27 15:09 PST, Robert Blaut
no flags Details
Standalone test case from Acid 3 suite (773 bytes, text/html)
2008-02-04 23:09 PST, Robert Blaut
no flags Details
Static test case from Acid3 suite (376 bytes, text/html)
2008-02-04 23:09 PST, Robert Blaut
no flags Details
test case with all 3 cases separated (801 bytes, text/html)
2008-02-04 23:11 PST, Robert Blaut
no flags Details
test case with all 3 cases separated (809 bytes, text/html)
2008-02-04 23:27 PST, Robert Blaut
no flags Details
test for treating text/html file as CSS file (355 bytes, text/html)
2008-02-05 05:24 PST, Robert Blaut
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-01-05 19:17:13 PST
Red square covers Acid3 test in Safari


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.
Comment 1 Eric Seidel (no email) 2008-01-05 19:17:53 PST
I will note that neither Opera or FF display the red square.
Comment 2 Eric Seidel (no email) 2008-01-06 00:31:46 PST
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?
Comment 3 Julian Reschke 2008-01-06 07:01:26 PST
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???
Comment 4 Eric Seidel (no email) 2008-01-07 07:34:24 PST
So this is the test in question:

    function () {
      // test 16: <object> handling and HTTP status codes
      var oC = document.createElement('object');
      var oB = document.createElement('object');
      var oA = document.createElement('object');
      oA.data = "support-a.png";
      oB.data = "support-b.png";
      oC.data = "support-c.png";
      // 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.
Comment 5 Eric Seidel (no email) 2008-01-14 16:04:38 PST
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.
Comment 6 Eric Seidel (no email) 2008-01-24 00:49:39 PST
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)
Comment 7 Robert Blaut 2008-01-27 15:09:12 PST
Created attachment 18724 [details]
Minimal test case
Comment 8 Dave Hyatt 2008-02-04 15:03:46 PST
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.

Comment 9 Dave Hyatt 2008-02-04 15:06:47 PST
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?

Comment 10 Dave Hyatt 2008-02-04 15:07:36 PST
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.

Comment 11 Robert Blaut 2008-02-04 23:09:02 PST
Created attachment 18927 [details]
Standalone test case from Acid 3 suite
Comment 12 Robert Blaut 2008-02-04 23:09:48 PST
Created attachment 18928 [details]
Static test case from Acid3 suite
Comment 13 Robert Blaut 2008-02-04 23:11:38 PST
Created attachment 18929 [details]
test case with all 3 cases separated
Comment 14 Robert Blaut 2008-02-04 23:17:55 PST
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.
Comment 15 Robert Blaut 2008-02-04 23:27:43 PST
Created attachment 18931 [details]
test case with all 3 cases separated

some issues in test case corrected.
Comment 16 Robert Blaut 2008-02-05 05:24:44 PST
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.
Comment 17 Robert Blaut 2008-02-05 05:30:29 PST
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.
Comment 18 Robert Blaut 2008-02-20 15:01:47 PST
*** Bug 16690 has been marked as a duplicate of this bug. ***
Comment 19 Robert Blaut 2008-02-20 15:04:30 PST
Another variant of the issue: http://biesi.damowmow.com/object/011.html
Comment 20 Robert Blaut 2008-02-20 15:08:10 PST
Many various tests for <object> MIME type handling are available on: http://biesi.damowmow.com/object/
Comment 21 Dave Hyatt 2008-02-20 18:00:25 PST
Fixed in r30438.