Closed Bug 84564 Opened 24 years ago Closed 24 years ago

Content-Style-Type no longer working

Categories

(Core :: CSS Parsing and Computation, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: ian, Assigned: peterv)

References

()

Details

(Keywords: css1, regression, testcase, Whiteboard: [Hixie-P2])

Attachments

(2 files)

STEPS TO REPRODUCE http://www.bath.ac.uk/%7Epy8ieh/internet/importtest/main/defaultlanguage.html ACTUAL RESULTS Red. EXPECTED RESULTS Green.
Blocks: html4.01
OS: Windows 2000 → Linux
Whiteboard: [Hixie-P2]
The original bug was bug 1962. It was VERIFIED FIXED a long time ago. cc'ing peterv, harishd, attinasi, dbaron: Any of you know how Content-Style-Type broke or how to fix it?
Something weird is happening in nsGenericHTMLElement::ParseStyleAttribute. After the following lines, isCSS is true even if styleType is "text/nosense". nsAutoString styleType; mDocument->GetHeaderData(nsHTMLAtoms::headerContentStyleType, styleType); if (0 < styleType.Length()) { static const char* textCssStr = "text/css"; isCSS = styleType.EqualsIgnoreCase(textCssStr, sizeof(textCssStr)); } I have a patch, but I'm a bit worried that this code stopped working, so I am going to cc Scc. Scott: any idea why the EqualsIgnoreCase above always returns true?
sizeof(char*) == 1 If you use char[] you can avoid that.
Then again, I think the patch you posted is better. r=dbaron
Thanks for pointing that out, David. Seems this broke when Pierre checked in his fix for bug 63502. Marc, could you please sr?
I'll take this.
Assignee: pierre → peterv
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → mozilla0.9.2
Status: NEW → ASSIGNED
sr=attinasi
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: