Bug 36515 – CSS style definitions are ignored if they just follow a "@charset" which appears in lines other than the first line in stylesheet.

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Hanrui]

Created attachment 51474 [details]
testcase 1

Browsers tested:
Safari 4.0.5(531.22.7): Fail
      Chrome 5.0.342.3: Fail
           Firefox 3.6: OK
                  IE 7: OK
                  IE 8: OK (In IE 8, it runs in IE7 Standards mode by page default)

What steps will reproduce the problem?
1. Launch the url in each browser
2. Pay attention to the top area of the page

What is the expected result?
Chrome and Safari should better show the same UI as that in IE and Firefox.

What happens instead?
In Chrome and Safari, the page loses the '新浪论坛' icon at the top-left 
side and shows the top login area is in a different color from that in IE 
and Firefox.

Please provide any additional information below. Attach a screenshot if
possible.

Thy this page: http://bbs.club.sina.com.cn/group.php?gid=26&tree=1
In its css file(http://sjs.sinajs.cn/tiezi/css/bbs2/dev.css?38.css), there 
are more than one "charset" lines. All style definition right following the 
charset lines will be missed expect the first charset line.
Yes, this issue is caused by mis-using of "charset", but why could not we 
handle it correctly while IE and Firefox both can?
Attached please kindly find my recuded test-case.
In my first test-case, the 2nd and 3rd selectors are both ignored in Safari 
and Chrome. But they are having effect in Firefox and IE.
And in the second test-case, you will see that the first selector which 
just follows the '@charset' right in the first line take effect while the 
second selector doesn't.
Thanks!

[Hanrui]

Created attachment 51475 [details]
testcase 2

[Jungshik Shin]

It's reported in Chromiub bug tracker (http://crbug.com/38877 )

[Alexey Proskuryakov]

See also: bug 18265. Seems that Firefox behavior is not what we thought it was.

[Adam Barth]

I'm not 100% clear on the expected behavior here.  Should we be ignoring these @charset directives or should we be switching charsets as we go?

[Alexey Proskuryakov]

The spec just says that such stylesheets are invalid, so all we can do is check other browsers' behavior.

My guess is that no browser switches the encoding. They may ignore misplaced charset declarations, or they may honor the first, or the last. The first option (ignoring) seems best and most likely to me in the absence of hard facts.

[Guido Jansen]

(In reply to comment #5)
> The spec just says that such stylesheets are invalid, so all we can do is check other browsers' behavior.
> 
> My guess is that no browser switches the encoding. They may ignore misplaced charset declarations, or they may honor the first, or the last. The first option (ignoring) seems best and most likely to me in the absence of hard facts.

in
http://www.w3.org/TR/CSS21/syndata.html#charset
it says 
"User agents must ignore any @charset rule not at the beginning of the style sheet."

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

See also: bug 21628.

[Alexey Proskuryakov]

Created attachment 65952 [details]
proposed fix

[WebKit Commit Bot]

Comment on attachment 65952 [details]
proposed fix

Rejecting patch 65952 from commit-queue.

Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--wait-for-httpd', '--ignore-tests', 'compositing,media', '--quiet']" exit_code: 1
Running build-dumprendertree
Compiling Java tests
make: Nothing to be done for `default'.
Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests
Testing 20871 test cases.
fast/loader/recursive-before-unload-crash.html -> failed

Exiting early after 1 failures. 14296 tests run.
254.34s total testing time

14295 test cases (99%) succeeded
1 test case (<1%) had incorrect layout
1 test case (<1%) had stderr output

Full output: http://queues.webkit.org/results/3881178

[Adam Barth]

Comment on attachment 65952 [details]
proposed fix

Sorry, that's a top flaky test.

[WebKit Commit Bot]

Comment on attachment 65952 [details]
proposed fix

Rejecting patch 65952 from commit-queue.

Failed to run "[u'git', u'svn', u'dcommit']" exit_code: 1
Last 500 characters of output:
ced-charset.html
	M	WebCore/ChangeLog
	M	WebCore/css/CSSGrammar.y
A repository hook failed: MERGE request failed on '/repository/webkit/trunk': Commit blocked by pre-commit hook (exit code 1) with output:

    The following files contain tab characters:

        trunk/LayoutTests/fast/css/misplaced-charset.html

    Please use spaces instead to indent.
    If you must commit a file with tabs, use svn propset to set the "allow-tabs" property.
 at /usr/local/git/libexec/git-core/git-svn line 572


Full output: http://queues.webkit.org/results/3856188

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/changeset/66486>.