234502 - linked stylesheet with invalid/unknown charset attribute results in stylesheet being ignored

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[D. D. Brierton]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

When in standards mode, Mozilla ignores linked stylesheets when the link element
has a charset attribute whose value is invalid and/or unknown. I discovered this
when I mistyped "ISO-8859-1" as "ISO-8895-1".

I'm not sure if this is a bug or intended behaviour, but thought I'd better
report it just to be on the safe side.

Reproducible: Always
Steps to Reproduce:

Comment 1

[D. D. Brierton]

Attachment: Test case

Comment 2

[Christopher Hoess (gone)]

Style System problem, although as I said, I don't believe this is actually a bug.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This doesn't depend on the rendering mode, actually.

The problem is that we get the bogus charset and give that to the unichar stream
loader.  This tries to create a Unicode decoder and fails.  The assumption is
then that the data is in a charset we don't support (which it is, as far as we
know) and we just return an error (see
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsUnicharStreamLoader.cpp#184)

I suppose we could do what the JS loader does and fall back to ISO-8859-1 if we
fail to get a decoder.... Darin, Jungshik, what do you think?

Note that it's also a tough call as to what the exact behavior is.... the
charset for the sheet comes from a long list of possible sources; if this
charset is bogus, would it be better to fall back on the next source instead of
ISO-8859-1?  That'd be much harder.....

Comment 4

[D. D. Brierton]

A comment that I should have added to the original report (I am the OP): this
doesn't happen in Moz 1.4 and earlier (the page with the typo in it has been
kicking around for ages and worked just fine in earlier versions of Moz). I have
an awful lot of sympathy with the view that this isn't a bug; however, one
counter-argument is that if a page with a typo in it like the one I reported has
been working for a long time in Mozilla but then suddenly doesn't in 1.6+ users
are likely to see it as a regression, even if technically it isn't.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, interesting.  This behavior changed as a result of bug 206379.  Before that
patch, as we checked each source we would ensure that we at least knew about the
existence of the charset (though not that we had a decoder for it) before
accepting it.  After that patch, we just pass the first nonempty charset string
we find on and then just bail if we can't get a decoder.

See
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-06-22+22%3A00%3A00&maxdate=2003-06-22+22%3A30%3A00&cvsroot=%2Fcvsroot

Comment 6

[Gabriel Sjoberg]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050902
Firefox/1.0+ ID:2005090207

This behavior persists in the above nightly.  Although (as the OP pointed out)
this isn't technically a bug, we'll let the devs decide what to do about it.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

The CSS and HTML working groups need to sort out how this is supposed to work...