WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
ASSIGNED
15242
Needs test: Improperly Linked CSS document (404) still loads contained styles
https://bugs.webkit.org/show_bug.cgi?id=15242
Summary
Needs test: Improperly Linked CSS document (404) still loads contained styles
Peter Peterson
Reported
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.
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
View All
Add attachment
proposed patch, testcase, etc.
Peter Peterson
Comment 1
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
Alexey Proskuryakov
Comment 2
2007-09-20 02:06:26 PDT
Confirmed with
r25667
(and with shipping Safari/WebKit).
Mark Rowe (bdash)
Comment 3
2007-09-20 06:36:36 PDT
<
rdar://problem/5494250
>
David Kilzer (:ddkilzer)
Comment 4
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.
mitz
Comment 5
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.
Mark Larson (Google)
Comment 6
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.
Dave Hyatt
Comment 7
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.
mitz
Comment 8
2008-02-04 15:10:15 PST
Should probably apply to other 4xx and 5xx codes.
Darin Adler
Comment 9
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?
Darin Adler
Comment 10
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().
Robert Blaut
Comment 11
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?
Alexey Proskuryakov
Comment 12
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.
mitz
Comment 13
2008-06-09 07:55:05 PDT
I think this was fixed by Hyatt for Acid3.
Robert Blaut
Comment 14
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/
Andrew Kulinich
Comment 15
2009-04-23 01:58:21 PDT
***
Bug 25326
has been marked as a duplicate of this bug. ***
Ahmad Saleem
Comment 16
2024-05-30 19:09:33 PDT
This started passing in 2008 and also from
Comment 14
, we only have this copy available:
https://web.archive.org/web/20050924094554/http://biesi.damowmow.com:80/object/002.html
Do we still want to add these test or they might be already covered one?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug