Closed Bug 136284 Opened 24 years ago Closed 24 years ago

CSS file fails to be recognized?

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 128896

People

(Reporter: daisuke, Assigned: attinasi)

References

(
URL
)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020408 BuildID: 20020408 The page http://www.snic.to/~shutopia/journal/daily.shtml is rendered without any CSS. All I see is a black and white page, but things like the h3 tag and such should have an orange-ish background. I think this has been happening for a little over a week. Reproducible: Always Steps to Reproduce: 1.just visit page 2. 3.
Something to do with <base /> probably...
WFM Linux 2002-04-15 CVS.
The style-sheet contains non-ascii chars in the definition of "font-family" for "strong.omomitsu". What encoding is that sheet in? Is it in iso-2022-jp or some other encoding?
The non-ascii characters inside .css file is encoding as shift-jis. Although there is Japanese font names in "strong.omomitsu", but actually at least this page is not using that style. But this page does use another Japanese font family in textarea (Osaka...) which is a Macintosh font family. That means, unless you have such kind of Mac fonts in your windows system, you won't see it display followed style sheet. This page is displayed fine with me on latast trunk and branch builds, maybe because this page changes daily. Reporter, could you please try again? thanks!
Yuying, thank you! The page is iso-2022-jp. The sheet had no charset info, so we used the page encoding to decode it. Decoding as iso-2022-jp failed because the actual encoding was shift-jis (and the chars were not valid iso-2022-jp). We now recover from decoding errors such as this one, so the sheet is now applied, though that one rule is still garbled due to the fact that the font name is completely incorrect after the error recovery.... But that can only be fixed by the site sending correct charset information. The error-recovery was put in in bug 128896 (it talks about the UTF-8 decoder, but it actually changed the CSSLoader to handle all decoder errors). *** This bug has been marked as a duplicate of 128896 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
just to confirm...I hadn't checked this page in three days, and yes, it works under the latest trunk. yey!
You need to log in before you can comment on or make changes to this bug.