Stylesheet with Content-Type header including unrecognized charset is ignored

RESOLVED DUPLICATE of bug 234502

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 234502
13 years ago
12 years ago

People

(Reporter: Vadim Shatalov, Assigned: smontagu)

Tracking

Trunk
x86
Windows Server 2003
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
I guess mozilla doesn't support that charset name... windows-1252 should work

Comment 2

13 years ago
WFM, Mozilla 2004-11-26-06 trunk Linux.
(Assignee)

Comment 3

13 years ago
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?
(Assignee)

Comment 4

13 years ago
(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
Summary: When Apache return http header "Content-Type: text/css; charset=win-1251" css don't locking good → Stylesheet with Content-Type header including unrecognized charset is ignored
(Assignee)

Comment 5

13 years ago
Created attachment 167208 [details] [diff] [review]
Tentative patch

This feels like using a sledgehammer to crack a nut, but it works at least.
Assignee: dbaron → smontagu
Status: UNCONFIRMED → ASSIGNED
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?
(Assignee)

Comment 7

13 years ago
(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.
> 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.
(Assignee)

Comment 9

13 years ago
OK, but in that case we should at least dump a message to the JS console as with
other CSS errors. 
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

12 years ago
Seems to be a dup of bug 234502

*** This bug has been marked as a duplicate of 234502 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.