Bug 15242 - Needs test: Improperly Linked CSS document (404) still loads contained styles
Summary: Needs test: Improperly Linked CSS document (404) still loads contained styles
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 25326 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-19 17:30 PDT by Peter Peterson
Modified: 2010-06-11 14:44 PDT (History)
8 users (show)

See Also:


Attachments
Example of improper loading of css styles from 404 document (289 bytes, text/html)
2007-09-19 17:34 PDT, Peter Peterson
no flags Details
Another test case for interpreting styles in a 404 page (1.71 KB, text/html)
2007-12-21 10:53 PST, Mark Larson (Google)
no flags Details
Patch that fixes this bug (1.05 KB, patch)
2008-02-04 15:05 PST, Dave Hyatt
darin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Peterson 2007-09-19 17:30:46 PDT
Observed behavior:
A CSS file is included on a page with an invalid path. A 404 html page is given in response by the server. The CSS styles on the 404 html page will be used on the original page.

Expected behavior: 
The contents of the returned 404 page are ignored.
Comment 1 Peter Peterson 2007-09-19 17:34:18 PDT
Created attachment 16329 [details]
Example of improper loading of css styles from 404 document

A 404 page is loaded as a CSS document. 

Observed behavior: 
"Normal" link is blue (browser default), "u link" is green, "l link" is grey

Expected behavior:
All links are the browser default color
Comment 2 Alexey Proskuryakov 2007-09-20 02:06:26 PDT
Confirmed with r25667 (and with shipping Safari/WebKit).
Comment 3 Mark Rowe (bdash) 2007-09-20 06:36:36 PDT
<rdar://problem/5494250>
Comment 4 David Kilzer (:ddkilzer) 2007-09-20 12:51:51 PDT
(In reply to comment #1)
> Created an attachment (id=16329) [edit]
> Example of improper loading of css styles from 404 document
> 
> A 404 page is loaded as a CSS document. 
> 
> Observed behavior: 
> "Normal" link is blue (browser default), "u link" is green, "l link" is grey

Note that this test only works if http://webkit.org/ is not in your browser history!  You'll either need to change the "http://webkit.org/" URL in the test to a URL that isn't in your browser history, or you need to clear your browser history through "Reset Safari" in the "Safari" menu.


Comment 5 mitz 2007-09-20 13:02:27 PDT
(In reply to comment #4)
> You'll either need to change the "http://webkit.org/" URL in the test
> to a URL that isn't in your browser history, or you need to clear your browser
> history through "Reset Safari" in the "Safari" menu.

You can delete individual history items in Safari's bookmarks viewer.
Comment 6 Mark Larson (Google) 2007-12-21 10:53:33 PST
Created attachment 18035 [details]
Another test case for interpreting styles in a 404 page

I confirmed this on Windows (Safari 3.0.4 523/13). I created a test case before finding this bug already filed. I've attached it FWIW (it uses a span.nav instead of an A, so it doesn't depend on your visited link history).

Curiously, the body{} style in the 404 response does not seem to get applied. Google's 404 reponse contains

<style><!--
body {font-family: arial,sans-serif}
div.nav {margin-top: 1ex}
div.nav A {font-size: 10pt; font-family: arial,sans-serif}
span.nav {font-size: 10pt; font-family: arial,sans-serif; font-weight: bold}
div.nav A,span.big {font-size: 12pt; color: #0000cc}
div.nav A {font-size: 10pt; color: black}
A.l:link {color: #6f6f6f}
A.u:link {color: green}
//--></style>

I haven't tested all the rules, but I've confirmed that span.nav gets applied but body does not.
Comment 7 Dave Hyatt 2008-02-04 15:05:01 PST
Created attachment 18920 [details]
Patch that fixes this bug

Not really sure if it is a good way to do it or not.  I just stop the feeding of data to the CachedResource when a 404 happens.
Comment 8 mitz 2008-02-04 15:10:15 PST
Should probably apply to other 4xx and 5xx codes.
Comment 9 Darin Adler 2008-02-04 15:11:06 PST
Comment on attachment 18920 [details]
Patch that fixes this bug

Why handle 404 different from other 4xx errors? What about 3xx and 5xx?
Comment 10 Darin Adler 2008-02-04 15:30:09 PST
Comment on attachment 18920 [details]
Patch that fixes this bug

I think the approach in this patch is OK, but it should be for all 4xx and 5xx, not specifically 404.

I also think that instead of calling data() and finish(), you should call error().
Comment 11 Robert Blaut 2008-06-09 04:54:52 PDT
I've tested the bug in Webkit r34382 on OS X and, to my surprise, the issue is not replicable in this build. This test https://bugs.webkit.org/attachment.cgi?id=18035 passes in the Webkit but still fails in stock Safari 3.1.1 for OS X. 

Any confirmations?
Comment 12 Alexey Proskuryakov 2008-06-09 06:14:59 PDT
I also cannot reproduce with this nightly. I think that it would make sense to isolate the revision that fixed this, and possibly to land a test case, if there isn't one already.
Comment 13 mitz 2008-06-09 07:55:05 PDT
I think this was fixed by Hyatt for Acid3.
Comment 14 Robert Blaut 2008-06-10 03:14:58 PDT
(In reply to comment #13)
> I think this was fixed by Hyatt for Acid3.
> 

Indeed, it was fixed in http://trac.webkit.org/changeset/30438 as part of fixing a bug: https://bugs.webkit.org/show_bug.cgi?id=16760

For LayoutTests I suggest to import these tests: http://biesi.damowmow.com/object/ 
Comment 15 Andrew Kulinich 2009-04-23 01:58:21 PDT
*** Bug 25326 has been marked as a duplicate of this bug. ***