* SUMMARY When a CSS stylesheet with no charset is first loaded, it gets the charset of the referring HTML document. If a second HTML document includes the exact same CSS stylesheet, the stylesheet will continue using the charset of the first document instead of the second. * STEPS TO REPRODUCE 1. Open the soon-to-be-attached test case on thie bug. 2. Open URL: http://simon.html5.org/test/css/syndata/representation/001.htm * RESULTS No matter how many times the page is reloaded, <http://simon.html5.org/test/css/syndata/representation/001.htm> always fails until the WebCore cache is cleared. * REGRESSION On shipping Safari 3.2.1, subsequent reloads of <http://simon.html5.org/test/css/syndata/representation/001.htm> appear to fix the encoding. On ToT WebKit, it doesn't change until the WebCore cache is cleared. * NOTES See Bug 11850 for the original analysis.
Created attachment 26182 [details] Test case (Step 1)
(In reply to comment #0) > * RESULTS > No matter how many times the page is reloaded, > <http://simon.html5.org/test/css/syndata/representation/001.htm> always fails > until the WebCore cache is cleared. Actually, clearing the WebCore cache doesn't seem to have an effect (nor does Cmd-Opt-E). The only way to fix the charset is to restart the browser.
When this bug is fixed, consider implementing (and thoroughly testing) this charset fallback mechanism: http://www.w3.org/TR/CSS21/syndata.html#charset
A somewhat more practical manifestation of the same problem is tracked as: <rdar://problem/5809774> Safari doesn't reload scripts once Text Encoding is changed. (In reply to comment #3) > When this bug is fixed, consider implementing (and thoroughly testing) this > charset fallback mechanism: > > http://www.w3.org/TR/CSS21/syndata.html#charset We have it implemented and tested already - are you aware of any bugs?
(In reply to comment #4) > (In reply to comment #3) > > When this bug is fixed, consider implementing (and thoroughly testing) this > > charset fallback mechanism: > > > > http://www.w3.org/TR/CSS21/syndata.html#charset > > We have it implemented and tested already - are you aware of any bugs? Great! I guess I was looking for one method where the fallback logic was contained, but couldn't find it upon initial inspection.
Using shift-reload fixes the problem in TOT. The bug here is that an existing cache entry should not be used if charset differs. The bug has been around for ever so it probably does not occur much in real world (though the recent reloading changes mean that it now needs shift-reload to fix instead of a regular reload).
This seems like a minor issue since it only affects cases where the same stylesheet is used with different encodings. If this really was a common issue, we would want to detect cases where the stylesheet was entirely ASCII and so not affected by the encoding, because it would be a shame not to share the cached stylesheet in that case. For testing and software development purposes, there could be some value to fixing this.
See also: bug 27802.