Closed Bug 37642 Opened 20 years ago Closed 19 years ago

error to console about user.css

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.2

People

(Reporter: sspitzer, Assigned: bzbarsky)

References

Details

(Keywords: helpwanted, polish)

Attachments

(9 files)

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.
adding sfraser to the bug.

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
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). 
Status: NEW → RESOLVED
Closed: 20 years ago
QA Contact: jelwell → jrgm
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
when i get this message, mozilla won't even startup! (RH Linux 6.2) 5-21-2000
mozbuild
I think the printouts should be in DEBUG only - it looks like the printouts 
(fputs and cerr) are not #ifdef'd
*** Bug 43928 has been marked as a duplicate of this bug. ***
Not an issue for NS6 end users, ->future
Target Milestone: --- → Future
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
*** Bug 51648 has been marked as a duplicate of this bug. ***
Isn't this bug history now?
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?
OS: Windows NT → All
Target Milestone: Future → mozilla0.8
Assignee: hyatt → dr
Status: REOPENED → NEW
yoink!
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.
Status: NEW → ASSIGNED
->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.
Keywords: helpwanted
Priority: P3 → P4
Target Milestone: mozilla0.8 → Future
*** Bug 68616 has been marked as a duplicate of this bug. ***
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.
Keywords: mozilla1.0
Status: ASSIGNED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → DUPLICATE
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
<disttsc@bart.nl> 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 ***
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?
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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 :-)
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
Added polish keyword
Keywords: polish
Randell, I've used NS_WARNINGs there.
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.
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
Status: REOPENED → ASSIGNED
ick! stupid editor. that should be:

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

hmph.
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.
Keywords: approval, patch
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.
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....
r=pink on mac build stuff
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.
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.
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.
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 :)
Assignee: dr → bzbarsky
Severity: normal → enhancement
Status: ASSIGNED → NEW
Keywords: mozilla0.9
Priority: P4 → --
Target Milestone: Future → ---
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.

I've filed bug 74759 on improving the default contents of userChrome.css. 
Suggestions are very very welcome.  :)
Blocks: 74759
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
Component: Browser-General → XP Apps
Hardware: PC → All
what does 'use MPL' mean?
Oh - good catch timeless.
 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.
this also has r=timeless on irc
Checked in, marking fixed.
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
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?
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...
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.
Blocks: 78472
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
reviews? 
Keywords: approvalreview
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);
Keywords: reviewapproval
r=timeless

conrad, would you file a new bug for that?
No longer blocks: 78472
any motion on this bug? it's gotten reviewed, where's the super review and 
approval?
Whiteboard: need sr= and a=
Target Milestone: --- → mozilla0.9.2
sr=alecf
Blocks: 83989
a=leaf
fix checked in
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Whiteboard: need sr= and a=
I'm still getting CSS loader errors in today's Win32 build...
Chad, did you create a new profile?
Yes.  (sorry I took so long, forgot to CC myself :)
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.