271840 - Stylesheet with Content-Type header including unrecognized charset is ignored

Status: RESOLVED DUPLICATE of bug 234502

(Core :: CSS Parsing and Computation, defect)

Description

[Vadim Shatalov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When Apache return http header "Content-Type:	text/css; charset=win-1251" css
don't locking good
If header is "Content-Type: text/css" with out charset all work

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

I guess mozilla doesn't support that charset name... windows-1252 should work

Comment 2

[Mats Palmgren (inactive)]

WFM, Mozilla 2004-11-26-06 trunk Linux.

Comment 3

[Simon Montagu :smontagu]

The chief reason that Mozilla doesn't support that character set name is that it
doesn't exist: in fact there are no registered character set names beginning
"win-". "windows-1251" would be the correct form.

Do we reject the whole style sheet if it has an illegal charset declaration?

Comment 4

[Simon Montagu :smontagu]

(In reply to comment #3)

> Do we reject the whole style sheet if it has an illegal charset declaration?

The answer to my own question seems to be "Yes":
http://smontagu.org/testcases/stylesheetencoding.html

Comment 5

[Simon Montagu :smontagu]

Attachment: Tentative patch

This feels like using a sledgehammer to crack a nut, but it works at least.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So...  There are 5 different sources for a charset in this code.  The last two
may not be relevant because maybe we vet them already, but there are three where
a charset may just be specified (HTTP header, @charset rule, charset attribute
on the node).  They should behave the same as far as this sort of thing goes.

Further, I feel that simply ignoring a charset declaration because we don't have
support for it and trying to treat it as some random other charset is wrong...
We do something similar for script (see bug 230104), but I'm really not to happy
with that either.

What do we do for toplevel documents that are encoded in a charset we don't
understand?

Comment 7

[Simon Montagu :smontagu]

(In reply to comment #6)
Yes, I agree that whatever we do for the charset declaration in the header
should be done for the other sources of charset info as well. This patch is
anyway only intended as a basis for discussion.

> I feel that simply ignoring a charset declaration because we don't have
> support for it and trying to treat it as some random other charset is wrong...

Do you agree that what we currently do is even more wrong? Which in effect is to
assume that if we find a charset declaration it must be OK, and then fail later
when we try to use it to decode the stylesheet.

Anyway, what I am suggesting is not that we should treat a charset that we don't
have support for as "some random other charset". We should just ignore it, like
an unknown CSS property, and pass on to the next possible source in the hope of
finding a charset that we do support.

P.S. Our current default for CSS is ISO-8859-1, but I just noticed that CSS 2.1
and the current working draft of the CSS3 Syntax module specify UTF-8 as the
last resort fallback. We should probably conform to that.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Do you agree that what we currently do is even more wrong?

Actually, no....  If the author explicitly specified a charset, we should use
that charset instead of second-guessing the author, imho.  If we don't support
that charset, we shouldn't apply the stylesheet, instead of possibly applying
the wrong stylesheet (gotten by treating the data as being in some other encoding).

I can see the argument for fixing up "author errors" here, but then we get into
a situation where we also "fix up" non-errors... which is not so great.

Comment 9

[Simon Montagu :smontagu]

OK, but in that case we should at least dump a message to the JS console as with
other CSS errors. 

Comment 10

[Boris Zbarsky [:bzbarsky]]

If the intl code reports the error to us in a useful way (i.e. other than just
having an empty stylesheet result), sure.

Comment 11

[Mathieu Parent]

Seems to be a dup of bug 234502

Comment 12

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 234502 ***