Closed Bug 162757 Opened 22 years ago Closed 22 years ago

CSS is not rendered when page has us-ascii charset selected in META tag

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 162593

People

(Reporter: chrisowens, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: regression) 

Using the latest-trunk build from tonight (15/08/02) and also build from
Saturday and Sunday of this last week, a few sites I have visited have not taken
into consideration the CSS'.

If I regress all the way back to last Friday (09/08/02) then the page renders
correctly.

Anyone else see this?

Not sure if it's a server/code bug, but this has only started happening since
Saturday (10/08/02) and the author says he has made no changes.

Confirm?
wfm with a 20min old CVS build on win2k.
Have you tried to clear your disk cache ?

WFM, 2002-08-13-04 trunk Linux.
Have cleared disk-cache and reinstalled... still here. :\

Going to completely re-install, kill all reg entries, kill prefs, cookies etc 
and see how it goes.

Will report back.
try this :
run "mozilla -profilemanager" and create an ADDITIONAL tets profile.
(close mozilla first)

Too late Matt, I nuked Moz. :D

Good news is that all is fine and dandy again. :)

Sorry, I normally nuke builds when i find a bug, but this one I didn't as it
didn't seem like it was an actual browser bug if you know what I mean.

Anyway, thanks for the help and I'll keep the tip in mind for next time.

Cheers
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Think I should close this, as its not a bug.

Closing
Status: RESOLVED → CLOSED
Please don't resolve bugs as FIXED unless code was checked in...
Status: CLOSED → UNCONFIRMED
Resolution: FIXED → ---
This bug was INVALID from the beginning...
Resolutions are documented here: http://bugzilla.mozilla.org/bug_status.html
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
Well excuse me for being a n00b. :\

I was only trying to help.

And thanks for the link.
invalid or worksforme is the correct resolution. 
(fixed only if a patch is attached and BTW: never use "closed")

Thanks for your help !
Nice that it works again...
Status: RESOLVED → VERIFIED
Thanks Matt.

I misunderstood the statuses, my fault.

Again, thanks all of you for your input & help.

Cheers
I am seeing this problem now with build 2002082608 PC/Win98.  It happens at this
URL and some others on the site (like the home page), but not all others.

Tried deleting and reinstalling and starting a new profile, but nothing changed.

Also oddly enough, when I mouse over most links on the page, the status bar does
not update.  When I mouse over the "feedback" link on the page (a mailto:), the
status bar updates with the mailto: URL and then it stays there after I mouse away.
Status: VERIFIED → UNCONFIRMED
Resolution: INVALID → ---
Also, I am not having this problem when viewing the site in the 1.1 Final.
Assignee: Matti → asa
Grrr... it's back again... this time re-installing and destroying my Moz profile
doesn't work.

Another URL that shows the problem is at :
http://charlottegraymovie.warnerbros.com/cmp/styleguide.html

It was designed by Zeldman.com / HappyCog afaik, so it should break in Moz... I
think. :)
Re: comment 14
I tested that URL and did not have a problem.

Marking bug as NEW based on bradsoft.com currently breaking for two of us now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I found the problem, though I'm not sure what this means:
I noticed that the W3C home page had lost its styles, and that both the W3C and
bradsoft.com page have META tags declaring the content type charset as
yus-ascii.  Going to View -> Character Coding in Mozilla and choosing another
coding (UTF-8 or  ISO-8859-1) suddenly brought back the styles.

I don't know if no styles under us-ascii constitutes a Moz bug or a web site
charset choice issue....  Reassigning bug to Style System to start triaging what
to do next.
Assignee: asa → dbaron
Component: Browser-General → Style System
QA Contact: asa → ian
@15

So when you view the charlotte gray site, you don't see it displayed in Times
New Roman?

Can you let me know what Build of Mozilla your using please, so I can check it out.

@Developers

This page has *never* displayed properly (view in IE to see correct page) using
Mozilla... from nightlies to final builds.
Re: comment 17
No, the page has always been fine for me.

Reference comment 12 for my build info.
ok Thanks Bill.

I've just nuked my prefs and user profile, as well as removed Moz reg entries...
and still the problem persists.

Funnily enough, the Bradsoft URL now works as intended, but the Charlotte Gray
site is still "broken".

Go figure!

Build 1.1 Final, WinXP
http://charlottegraymovie.warnerbros.com/cmp/styleguide.html
has a DOCTYPE that implies "Standards compliance mode" and the site is
serving their CSS as "application/x-pointplus" rather than "text/css"

--> Tech Evangelism


> curl -I http://charlottegraymovie.warnerbros.com/cmp/styles/charlotte.css
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Sun, 01 Sep 2002 14:49:32 GMT
Content-type: application/x-pointplus
Set-cookie:
WBWTID=213.114.166.58-3D7228FC3C1000000A415CD-charlottegraymovie-phoebe; path=/;
expires=Friday, 01-Jan-10 12:00:00 GMT; domain=.warnerbros.com;
Etag: "1feb5807-1-590-3c7512c9"
Last-modified: Thu, 21 Feb 2002 15:31:21 GMT
Content-length: 1424
Accept-ranges: bytes
Assignee: dbaron → susiew
URL: http://www.bradsoft.com/topstyle/blog... → http://charlottegraymovie.warnerbros....
Component: Style System → US General
OS: Windows XP → All
Product: Browser → Tech Evangelism
QA Contact: ian → zach
Hardware: PC → All
Version: other → unspecified
This bug isn't even about that URL!

It's about either of these URLs, which *are* being served correctly but their
CSS does not show:
http://www.bradsoft.com/topstyle/blog/index.asp
http://www.w3.org/

I already explained why they aren't showing up.
If someone's that worried about Charlotte Grey, that should be its own bug.
Changing the bug back to its previous settings.
Assignee: susiew → dbaron
URL: http://charlottegraymovie.warnerbros.... → http://www.bradsoft.com/topstyle/blog...
Component: US General → Style System
OS: All → Windows XP
Product: Tech Evangelism → Browser
QA Contact: zach → ian
Hardware: All → PC
Summary: CSS is not taken into consideration when rendering page. → CSS is not rendered when page has us-ascii charset selected in META tag
Version: unspecified → other
Chill out Bill.. :)

The way I understood it was that the Charlotte Gray site was being affected by 
the same problem, as *no* CSS formatting shown when viewing with Moz... it's 
been shown that it's a differant bug, and thats a good thing (sort of).

I don't think we should leave it up to someone to be "that bothered" to submit 
a bug about either the page/server config... as imo, it's a Mozilla bug too, 
IE/Opera etc, all display the page as it was intended to be displayed.

Is the bug not even slightly related? - Curious why both bugs displayed 
themselves at the same time.

And is/will/has someone submitted a bug re: Charlotte Gray?

If not, and no-one wants to, then let me know and I will... I'd search myself 
at the moment, but I *have* to go out now.
Added kw regression.

Re: comment 23
I'm not planning to file a bug for that site.
Keywords: regression
re: Comment 23

Bill, I've now filed a new bug for the Charlotte Gray site.

I don't have access to my own computer at the moment, so can anyone confirm 
the charlotte gray problem still exists in latest build?

http://bugzilla.mozilla.org/show_bug.cgi?id=166133
I suspect this problem may be caused by the big disaster in bug 162593, as:

1) after I did the workarounds there to fix that problem, this problem stopped
2) some people there reported loss of CSS on pages as a symptom
3) this bug was originally opened one day after 162593 got started

My suggestion would be to retest the bradsoft.com and w3.org URLs with the 1.2
alpha when it comes out, since the patch for 162593 will be in it.  If the pages
work, this bug can be resolved as a duplicate of that one.
Could someone retest after the fix to that bug goes in, and mark as duplicate if
it is fixed?
Tested this morning with build 2002090504 PC/Win98 and both bradsoft.com and
w3.org appear fine.  Resolving bug as dup of bug 162593.

*** This bug has been marked as a duplicate of 162593 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.