mozilla is no longer using userChrome.css in profiles, nor is it loading CSS via file: When loading an XHTML page with this line, the CSS is applied in 2002100208. In todays build, no css is applied. <link rel="stylesheet" type="text/css" href="generic.css" media="screen" title="clean" /> Cc'ing walk as timeless says he mentioned something about this in IRC earlier today.
-> me ... someone is incorrectly generating a nsIURI by instantiating a nsStandardURL and then expecting the file protocol handler to load it! gotta track down and fix whomever is creating that nsIURI.
Assignee: dbaron → darin
Severity: critical → blocker
Status: NEW → ASSIGNED
Keywords: mozilla1.2, regression
Priority: -- → P1
Target Milestone: --- → mozilla1.2beta
Hmm... So I just looked and all of nsChromeRegistry (this loads user*.css), nsStyleLinkElement (handles loads of <link>, eg), and nsCSSParser (handles @import rules in CSS) are using NS_NewURI to create the nsIURI object from the string...
nevermind, the real problem is that nsStandardURL::Clone doesn't "clone" mSupportsFileURL :-( ... easy enough to fix.
Component: Style System → Networking
here's the patch that i just checked in: Index: nsStandardURL.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp,v retrieving revision 1.37 diff -u -r1.37 nsStandardURL.cpp --- nsStandardURL.cpp 6 Oct 2002 02:20:27 -0000 1.37 +++ nsStandardURL.cpp 6 Oct 2002 19:30:08 -0000 @@ -1486,6 +1486,7 @@ clone->mFile = mFile; clone->mHostA = mHostA ? nsCRT::strdup(mHostA) : nsnull; clone->mMutable = PR_TRUE; + clone->mSupportsFileURL = mSupportsFileURL; clone->mHostEncoding = mHostEncoding; clone->mSpecEncoding = mSpecEncoding; marking FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
sr=me for that patch, a little posthumously. ;)
v, userChrome and web pages with css via file:
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.