37642 - error to console about user.css

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, enhancement)

Description

[(not reading, please use [e-mail] instead)]

OpenChromURL(chrome://messenger/content/messenger.xul,-1,-1)
WEBSHELL+ = 2
CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///D|/seamonkey/mozilla/dist/WI
N32_D.OBJ/Users50/sspitzer/chrome/user.css' failed.  Error code: 18
plugins at: C:\Program Files\Netscape\Communicator\Program\Plugins
plugins at: D:\seamonkey\mozilla\dist\WIN32_D.OBJ\bin\plugins

I don't have a user.css.

Comment 1

[(not reading, please use [e-mail] instead)]

adding sfraser to the bug.

Comment 2

[R.K.Aa.]

2000-050308: On Linux the error during startup looks like this:

CSSLoaderImpl::LoadAgentSheet: Load of URL
'file:///home/dark/.mozilla/default/chrome/user.css' failed.  Error code: 16389

Comment 3

[John Morrison]

The answer on this one is that you can have a "sspitzer/chrome/user.css" in 
your profile directory -- this gives you a user stylesheet with which to 
set overrides on XUL and HTML css (e.g., boost the font-size: in menu's, etc.)
See postings by hyatt in .xpfe and akkana in .unix. (e.g, 
news://news.mozilla.org/390DDFBE.F7A247C2%40netscape.com)

So, unless this is a request to silence the message in the console, then I'm
resolving this bug as invalid (not a bug). 

Comment 4

[(not reading, please use [e-mail] instead)]

this bug is to quiet that message.

here's why I suggest you quiet it:

you'll get a lot of bugs and people will see that in the console, and think it
has something to do with it, when it is harmless.

why confuse people?

reopening.

Comment 5

[Simon Fraser [no longer active]]

That printf occurs for *any* missing CSS file, not just user.css, and we want to 
get the error for other cases.

Why don't we just install an empty user.css in a new profile. People may start 
using this anyway to implement various layout-related prefs.

Comment 6

[jr]

when i get this message, mozilla won't even startup! (RH Linux 6.2) 5-21-2000
mozbuild

Comment 7

[Marc Attinasi]

I think the printouts should be in DEBUG only - it looks like the printouts 
(fputs and cerr) are not #ifdef'd

Comment 8

[R.K.Aa.]

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

Comment 9

[Peter Trudelle]

Not an issue for NS6 end users, ->future

Comment 10

[David Krause]

Maybe the message should be changed from "failed" to something that doesn't
sound as bad.  Usually failed would mean that something really bad has occured,
but in this case it doesn't.  It's more of a warning than an error.

Or do something along the lines of:
1) if file exists try to load it
2) if it doesn't exist don't try to load it
i think that would get rid of the error

Comment 11

[R.K.Aa.]

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

Comment 12

[R.K.Aa.]

Isn't this bug history now?

Comment 13

[rbs]

The lack of stubs for userContent.css and userChrome.css is making their
discovery impossible. They are undocumented and even when people hear about
them, they are confused as to where to put them. It will be helpful to have the
stubs so that at least people can search and edit them on their respective
platforms. Any takers if hyatt is fishing elsewhere?

Comment 14

[Dan Rosen]

yoink!

Comment 15

[Dan Rosen]

seems like a couple things should happen: an empty user(*).css should be
installed by default into a user's profile, the warnings should be ifdef'ed, and
the warning itself should use less strong language. that's the general idea of
what people have been saying in this bug... speak up if i've missed something.
i'll put together a patch.

Comment 16

[Peter Trudelle]

->Future/help wanted.  Is this is really blocking someone, or causing any
significant problems, please nominate for a target milestone by adding the
corresponding keyword.

Comment 17

[timeless]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

nominating for mozilla1.0.  This is a polish issue...  By 1.0 we should
hopefully not be printing any extra debug output in non-debug builds.

Comment 19

[timeless]

jag: did you fix this? please verify.
it seems like this was fixed by 

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/style/src/nsCSS
Loader.cpp&rev=3.70#1531 #ifdef DEBUG
<[e-mail]> 03 Feb 2001 01:09
Replace iostream.h cerr << dependancy with NS_WARNING. bug=67536, r=jst, 
sr=blizzard

*** This bug has been marked as a duplicate of 67536 ***

Comment 20

[rbs]

It is good to have the stubs. Otherwise this feature is confusing and
undiscoverable. Re-opening and cc:ing jag... want to take this, jag?

Comment 21

[Peter "jag" Annema]

The stubs should still be made, with some nice comments in them about what they
do. I'm not sure how discoverable this is, but it's better than nothing.

I don't think the language needs to be less strong now that's it's #ifdef DEBUG.

If I want to do this? On a rainy day perhaps, in which case I'll take the bug
from dr at that point :-)

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

We should not be throwing Asserts in the normal course of operation.  I'm quite
sure I never had a userChrome.css, but I wasn't getting Asserts until the last
week or two.

As for why we shouldn't Assert for harmless cases, I always run with breakpoints
on nsDebug::Assert, so when there _is_ an Assert I can investigate and report
it, especially if it may be tough to repeat.

IMHO

Comment 23

[Randell Jesup [:jesup] (needinfo me)]

Added polish keyword

Comment 24

[Peter "jag" Annema]

Randell, I've used NS_WARNINGs there.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to create the stubs for a new profile

Comment 26

[Boris Zbarsky [:bzbarsky]]

I've tested this patch on Linux.  Could someone test it on windows?  I'm fairly
sure I got all the makefile.win stuff right, but if someone could check that
would be great.

This does not deal with migrated profiles, just new ones.

Comment 27

[Dan Rosen]

bzbarsky: your patch looks pretty good. as a stylistic point, i'd ask that you
change the examples to look like this:

/*
* example: turn off "blink" element blinking
*
* blink { text-decoration: none ! important; }
*/

so there is no confusion on the part of a novice css hacker as to whether the
css rule is in the comment block or not.

i can't comment on your makefile-fu, since i don't know how those install
targets work (esp. on windows), but if you're pretty sure they do what they're
supposed to, then i won't argue. did you remember to modify
profile/defaults/makefile.win?

r=dr, if you make the changes to the css example, and if you're sure the
makefiles are all good. leave the bug open after (and if) you check in, though,
since i'm still going to want to weaken the language in the warning message and
#ifdef debug it. (or you could fix that too, nudge nudge wink wink)

thanks! -dr

Comment 28

[Dan Rosen]

ick! stupid editor. that should be:

/*
 * example: turn off "blink" element blinking
 *
 * blink { text-decoration: none ! important; }
 */

hmph.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch fixing the comments in the CSS as dr asks

Comment 30

[Boris Zbarsky [:bzbarsky]]

updated the CSS files to have the less confusing comments.

The makefiles have now been tried on Linux and Windows and work on both.

The message is already in #ifdef debug, by the way...

We should also keep this open because we need to create these stubs for migrated
profiles too.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch 3 -- for migrated profiles (completely independent of patch 2)

Comment 32

[Simon Fraser [no longer active]]

This won't work on Mac:

diff -u -N -r profile/defaults/MANIFEST profile/defaults/MANIFEST
--- profile/defaults/MANIFEST   Mon Mar  5 22:10:49 2001
+++ profile/defaults/MANIFEST   Mon Mar  5 22:09:26 2001
@@ -3,3 +3,4 @@
 localstore.rdf
 search.rdf
 mimeTypes.rdf
+chrome

You can't add a directory to a MANIFEST file. You'll have to create a new 
MANIFEST file inside the chrome dir which lists all the files you want to export. 
You then need to add this MANIFEST file to the list of MANIFESTs in 
MozillaBuildList.pm.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch 4 -- fix the Mac stuff in patch 2

Comment 34

[Boris Zbarsky [:bzbarsky]]

Could someone please review patch 3 and patch 4?  Patch 3 depends on patch 4 to
work, so patch 4 should be checked in first....

Comment 35

[Mike Pinkerton (not reading bugmail)]

r=pink on mac build stuff

Comment 36

[rbs]

marc, mind giving a sr? you are the only one in the cc:list entitled to do so.
looks like things are ready to go.

Comment 37

[Marc Attinasi]

I'm not really comfortable sr'ing makefile changes because I know very little
about them, however if they are reviewed by knowledgable people, and tested
thoroughly (preferably by a couple of people, and certainly on each platform
Win, Mac and Linux)) then I'll be happy to rubber-stamp an sr=attinasi.

The comments in the css file stubs are nice, but I think it might be good to
indicate why the !important is necessary for all of the rules in there. It is
not standard CSS to require that for a user stylesheet, so indicating that it is
in fact required now but may not be in the future is probably a good idea.

On nit in the code that handles the profile migration, and this is a really
small nit: how can you justify asserting that a copy operation succeeds? Have
you previously tested that the disk has enough space, that it is writable, that
it is not removable? Handling the error is the correct thing to do, but
accessing the file system is rarely (never?) something that you can guarantee
success on so you should not assert success.

Comment 38

[Simon Fraser [no longer active]]

Minor nit: please make the default 'userChrome.css' platform-neutral, instead of 
containng Irix-related styles.

Second point; it would be nice to be able to install different userChrome.css 
files on different platforms (Mac's could set the window font to Geneva 9, for 
example). Not sure if it's worth checking in 3 different userChrome.css for that 
though.

Comment 39

[Dan Rosen]

Hm, I second that desire. AFAIK, we use system fonts/sizes on unix and win32,
but I don't know about mac... The scope of this bug is limited, though, and it'd
probably be nice to have this checked in anyway. Once the code is in the tree we
can file new bugs for related enhancements.

I suggest you clear up the "minor nitpicks" and checkin with attinasi's
rubberstamp :)

Reassigning to bzbarsky, since he's the one doing the work anyway :)

Comment 40

[Boris Zbarsky [:bzbarsky]]

I was asserting on copy there because I had modeled my code on the other code
that used to be there that copied over missing files as necessary.  That other
code is gone.  And when I think about it, there is no reason to assert -- simply
returning with an error should be fine.

Attaching a patch that removes the asserts.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Attachment: combined patch for the whole thing

Comment 42

[Boris Zbarsky [:bzbarsky]]

I've filed bug 74759 on improving the default contents of userChrome.css. 
Suggestions are very very welcome.  :)

Comment 43

[Boris Zbarsky [:bzbarsky]]

Attachment: oops. Combined patch with explanations of !important

Comment 44

[timeless]

bz: please use MPL
+++ profile/defaults/chrome/Makefile.in Mon Mar  5 22:09:26 2001
+++ profile/defaults/chrome/makefile.win        Mon Mar  5 22:09:26 2001

Comment 45

[Marc Attinasi]

what does 'use MPL' mean?

Comment 46

[Boris Zbarsky [:bzbarsky]]

Attachment: Using Mozilla Public License instead of Netscape Public License as timeless suggests

Comment 47

[Marc Attinasi]

Oh - good catch timeless.

Comment 48

[Mike Shaver (:shaver emeritus)]

 rv = userChromeDir->Create(nsIFile::DIRECTORY_TYPE, 0775);

That worries me a little: if another user can alter my userChrome.css, they can
basically execute code as me.  Yikes!

I realize that you didn't change it, but I think 0755 is a better mode there,
and it'd be nice if you could fix it while you're in there.

What about including a reference to akk's unix/customizing.html doc from the
sample sheets?

Other than that, sr=shaver.  Nice work.

Comment 49

[Boris Zbarsky [:bzbarsky]]

Attachment: make the changes shaver suggests

Comment 50

[Boris Zbarsky [:bzbarsky]]

this also has r=timeless on irc

Comment 51

[Peter "jag" Annema]

Checked in, marking fixed.

Comment 52

[rbs]

I updated my tree on Win32 -- but I am still getting the warnings about the
missing files. I thought a rebuild will pick things up -- isn't that the case?

Comment 53

[Boris Zbarsky [:bzbarsky]]

Well... if you look, we are creating the user*.css files in one of two cases:

1)  When a new profile is created
2)  when an already existing profile does not have a "chrome" folder and the 
"chrome" folder is created.

Case 2 handles migrated profiles, which do not have a "chrome" folder created 
during profile migration.

Existing profiles that have a "chrome" folder are not affected by this patch...

Comment 54

[Boris Zbarsky [:bzbarsky]]

So... um... reopening.  The paths in Makefile.in are wrong, so the files are not
being placed in the right place.  The paths in makefile.win are right... 

As a result this bug is _not_ fixed on Unix in current builds.  Patch coming up.

Comment 55

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix the paths

Comment 56

[Boris Zbarsky [:bzbarsky]]

reviews? 

Comment 57

[Conrad Carlen (not reading bugmail)]

I'd say all of this code that was added to nsChromeRegistry.cpp was added in the
wrong place. What should have been done is that a directory services key should
have been defined for these two files, and that the directory service provider
in profile mgr should provide these locations. Then, this whole mess of code
which was added would gone and in profile mgr, it would reduce to:
 rv = EnsureProfileFileExists(localFile);

Comment 58

[timeless]

r=timeless

conrad, would you file a new bug for that?

Comment 59

[andreww]

any motion on this bug? it's gotten reviewed, where's the super review and 
approval?

Comment 60

[Alec Flett]

sr=alecf

Comment 61

[Daniel (Leaf) Nunes]

a=leaf

Comment 62

[Boris Zbarsky [:bzbarsky]]

fix checked in

Comment 63

[Chad Austin]

I'm still getting CSS loader errors in today's Win32 build...

Comment 64

[Boris Zbarsky [:bzbarsky]]

Chad, did you create a new profile?

Comment 65

[Chad Austin]

Yes.  (sorry I took so long, forgot to CC myself :)