Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

userChrome Oddity

11 views
Skip to first unread message

Ken Whiton

unread,
Sep 18, 2007, 9:44:18 PM9/18/07
to
I'm running TB1.5 [User-Agent: Thunderbird 1.5 (Windows/20051201)]
under Windows ME on my desktop machine, and under Windows XP (Home,
SP2) on my laptop. On both machines I have the following entry (among
others) in my userChrome.css file:

/* Set Colors In Message Pane/Window Header */

#msgHeaderView {
background-color: red !important; }

On the desktop this gives me:

1. a red background in the header area of the Message Pane/Window
(which is what I wanted from the entry),
and
2. a red background/frame around the attachment list when reading
a message/post containing one or more attachments. I hadn't
originally wanted this, but it's a nice bonus.

On the laptop, however, I get Number 2 (the nice bonus) but not
Number 1 (the desired effect). :-(

Does anyone know why I don't get the same results on both
machines, and how I can get the desired result on the laptop? FWIW,
I use TBird's default theme, and the only extensions I have installed
are MessageFaces 1.1.2 and DOM Inspector 1.8 (same on both machines).

Ken Whiton

FIDO: 1:132/152
InterNet: kenw...@surfglobal.net.INVAL (remove the obvious to reply)

Message has been deleted

Ken Whiton

unread,
Sep 19, 2007, 10:37:42 PM9/19/07
to
*-* On Tue, 18 Sep 2007 22:09:45 -0400,
*-* In Article 8p6dnR782OSWGG3b...@mozilla.org,
*-* Ron K. wrote
*-* About Re: userChrome Oddity

> 9/18/2007 9:44 PM I read Ken Whiton wrote

>> #msgHeaderView {
>> background-color: red !important; }

> What I do not understand is why You get Red around the
> #attachmentView.

Ooopppsss! I went back and looked at the *WHOLE* file and found
that I have a separate entry setting the #attachmentView to red:

/* Attachment Pane At Bottom Of Message Window */

#attachmentView {
-moz-appearance: none !important;
height: 66px !important; overflow: auto !important;
background-color: red !important; }

I had forgotten that I set that. That solves that part of the
mystery. Now all I have to do is get the header to turn red on the
laptop. Any ideas?

> Is that view down at the bottom as a bar just over the status bar?

Yes.

Message has been deleted

Ken Whiton

unread,
Sep 20, 2007, 11:17:12 PM9/20/07
to
*-* On Thu, 20 Sep 2007 02:57:32 -0400,
*-* In Article geedndpOl8ffh2_b...@mozilla.org,

*-* Ron K. wrote
*-* About Re: userChrome Oddity

> 9/19/2007 10:37 PM I read Ken Whiton wrote
>> *-* Ron K. wrote

>>> 9/18/2007 9:44 PM I read Ken Whiton wrote

>>>> /* Set Colors In Message Pane/Window Header */

>>>> #msgHeaderView {
>>>> background-color: red !important; }

>>>> Does anyone know why I don't get the same results on both


>>>> machines, and how I can get the desired result on the laptop?
>>>> FWIW, I use TBird's default theme, and the only extensions I have
>>>> installed are MessageFaces 1.1.2 and DOM Inspector 1.8 (same on
>>>> both machines).

>> I had forgotten that I set that. That solves that part of the


>> mystery. Now all I have to do is get the header to turn red on the
>> laptop. Any ideas?

> #msgHeaderView { background-color: red !important; }

> My first suggestion calls for good proof reading.

Would a binary comparison (actually two different ones) of the
copies of the file on the two machines) be good enough? :-)

> A missing ! or a
> typo can kill a CSS declaration. Also a Case error in the selector
> name could be a suspect. I have had these sort of errors bug my
> efforts to alter the look of SPC theme. With SPC I get a red
> gradient GIF being applied where your trying to get color by CSS.

I doubt that's the problem here. I have a home network, and both
machines are on it. After I installed TBird on the laptop I set it up
by copying the contents of the default profile folder
(????????.default) from the desktop to the laptop. Everything else
works fine, and when this anomaly appeared I checked the laptop and
desktop copies of the file against one another using the
above-mentioned two different binary compares, neither of which found
any differences between the two files. They're identical, yet the
entry works on the desktop but not on the laptop. :-(

Message has been deleted

dillinger

unread,
Sep 23, 2007, 4:05:49 PM9/23/07
to
Ron K. wrote:
> 9/20/2007 11:17 PM I read Ken Whiton wrote
> May be the text color name is not taking. could try the Hex code or the
> rgb(255,0,0) alternative. I ran into one case of a color by name
> problem with the SPC theme, just could not get a color change to kick
> in. This is the last idea I can think off to try.
>
> #msgHeaderView { background-color: #ff0000 !important; }
>

Try this:

/* Set Colors In Message Pane/Window Header */

#expandedHeaders,
#collapsedHeaderView {
background-color: red !important;
}

Michel.

Ken Whiton

unread,
Sep 23, 2007, 4:33:33 PM9/23/07
to
*-* On Fri, 21 Sep 2007 00:47:39 -0400,
*-* In Article mJSdnbK_h_EC0G7b...@mozilla.org,

*-* Ron K. wrote
*-* About Re: userChrome Oddity

> 9/20/2007 11:17 PM I read Ken Whiton wrote
>> *-* Ron K. wrote

[ ... ]

>>> #msgHeaderView { background-color: red !important; }

>>> My first suggestion calls for good proof reading.

>> Would a binary comparison (actually two different ones) of the
>> copies of the file on the two machines) be good enough? :-)

>>> A missing ! or a
>>> typo can kill a CSS declaration. Also a Case error in the
>>> selector name could be a suspect. I have had these sort of errors
>>> bug my efforts to alter the look of SPC theme. With SPC I get a
>>> red gradient GIF being applied where your trying to get color by
>>> CSS.

>> I doubt that's the problem here. I have a home network, and
>> both machines are on it. After I installed TBird on the laptop I
>> set it up by copying the contents of the default profile folder
>> (????????.default) from the desktop to the laptop. Everything else
>> works fine, and when this anomaly appeared I checked the laptop and
>> desktop copies of the file against one another using the
>> above-mentioned two different binary compares, neither of which
>> found any differences between the two files. They're identical,
>> yet the entry works on the desktop but not on the laptop. :-(

> May be the text color name is not taking. could try the Hex code or


> the rgb(255,0,0) alternative. I ran into one case of a color by
> name problem with the SPC theme, just could not get a color change
> to kick in. This is the last idea I can think off to try.

> #msgHeaderView { background-color: #ff0000 !important; }

I tried both the hex and RGB methods of specifying the color with
no change. Just for the heck of it I also tried using a couple of
different colors, also with no change in the results. What's so
puzzling (and aggravating) is that it works on the desktop, but not on

Ken Whiton

unread,
Sep 23, 2007, 5:10:34 PM9/23/07
to
*-* On Sun, 23 Sep 2007 22:05:49 +0200,
*-* In Article uhtis4-...@picard.home,
*-* dillinger wrote

*-* About Re: userChrome Oddity

> Ron K. wrote:


>> 9/20/2007 11:17 PM I read Ken Whiton wrote

>>> *-* Ron K. wrote

[ ... ]

>>>> #msgHeaderView { background-color: red !important; }

>>>> My first suggestion calls for good proof reading.

>>> Would a binary comparison (actually two different ones) of
>>> the copies of the file on the two machines) be good enough? :-)

>>>> A missing ! or
>>>> a typo can kill a CSS declaration. Also a Case error in the
>>>> selector name could be a suspect. I have had these sort of
>>>> errors bug my efforts to alter the look of SPC theme. With SPC I
>>>> get a red gradient GIF being applied where your trying to get
>>> color by CSS.

>>> I doubt that's the problem here. I have a home network, and
>>> both machines are on it. After I installed TBird on the laptop I
>>> set it up by copying the contents of the default profile folder
>>> (????????.default) from the desktop to the laptop. Everything
>>> else works fine, and when this anomaly appeared I checked the
>>> laptop and desktop copies of the file against one another using
>>> the above-mentioned two different binary compares, neither of
>>> which found any differences between the two files. They're
>>> identical, yet the entry works on the desktop but not on the
>>> laptop. :-(

>> May be the text color name is not taking. could try the Hex code


>> or the rgb(255,0,0) alternative. I ran into one case of a color by
>> name problem with the SPC theme, just could not get a color change
>> to kick in. This is the last idea I can think off to try

>> #msgHeaderView { background-color: #ff0000 !important; }

> Try this:

> /* Set Colors In Message Pane/Window Header */
> #expandedHeaders,
> #collapsedHeaderView {
> background-color: red !important;
> }

> Michel.

*BINGO*!!!! That did the trick, thank you very much. Thanks to
Ron, too, for his efforts to help. I'm still curious about why my
original version works on my desktop, but not on my laptop, though.

Message has been deleted

Phillip M. Jones, C.E.T

unread,
Sep 23, 2007, 7:49:11 PM9/23/07
to

Different version of Windows/MacOS/UNIX/LINUX?

I have OX.4.10 on my PowerBook laptop, and X.3.9 on my Desktop.

And items such as Disk Utility > Repair Permissions works totally
different on both. If you use system's disk to repair permission on
Desktop with system's disk from Laptop it will get permissions totally
out of whack. Or the other way around.

Turns out the UNIX core on X.3.9 is "BSD UNIX" while X.4.10 it "FreeBSD
UNIX", a totally different animal.

--
------------------------------------------------------------------------
Phillip M. Jones, CET http://www.vpea.org
If it's "fixed", don't "break it"! mailto:pjo...@kimbanet.com
http://www.kimbanet.com/~pjones/default.htm
Mac G4-500, OSX.3.9 Mac 17" PowerBook G4-1.67 Gb, OSX.4.10
------------------------------------------------------------------------

dillinger

unread,
Sep 23, 2007, 9:16:43 PM9/23/07
to
Ron K. wrote:
> 9/23/2007 5:10 PM I read Ken Whiton wrote
> This fix suggests that on the laptop the proper node is not being found,
> so gets ignored. I agree, it's odd, but there are some 9X verses NT/XP
> differences that have been accommodated in the code. That all goes away
> in the future with droppage of 9X support.
>

Maybe so, apparently -moz-appearance settings cannot always be overruled
unless they are explicitly turned off, check:

#msgHeaderView {
-moz-appearance: none !important;
background-color: red !important;}

That works, on the other hand, 'deeper' nodes always seem to overrule
'higher' nodes, check:

#expandedHeaderView,
#collapsedHeaderView {
background-color: red !important;}

or:

#msgHeaderViewDeck {
background-color: red !important;}

or:

#msgHeaderViewDeck {
background-color: red !important;}
expandedfromBox {
background-color: lime !important;}
#expandeddateBox {
background-color: yellow !important;}

All work, the last one also changes the background color of some of the
lines (boxes) in the header.

Michel.

Message has been deleted

Ken Whiton

unread,
Sep 29, 2007, 1:06:03 AM9/29/07
to
*-* On Sun, 23 Sep 2007 22:36:17 -0400,
*-* In Article VKWdna48C9jFv2rb...@mozilla.org,
*-* Ron K. wrote

*-* About Re: userChrome Oddity

I accidentally "deleted" dillinger's post, so I'm replying to
Ron's subsequent post. :-(

> 9/23/2007 9:16 PM I read dillinger wrote


>> Ron K. wrote:
>>> 9/23/2007 5:10 PM I read Ken Whiton wrote

>>>> *-* dillinger wrote

[ ... ]

>>>>> Try this:

>>>>> /* Set Colors In Message Pane/Window Header */
>>>>> #expandedHeaders,
>>>>> #collapsedHeaderView {
>>>>> background-color: red !important;
>>>>> }

>>>>> Michel.

>>>> *BINGO*!!!! That did the trick, thank you very much.
>>>> Thanks to Ron, too, for his efforts to help. I'm still curious
>>>> about why my original version works on my desktop, but not on my
>>>> laptop, though.

Having used that code for a few days now, I find it's not exactly
what I want. Using my original code, on the desktop, the header area
is completely colored, and MessageFaces displays images against the
colored background. Using the above code, on the laptop, the color
stops about 1/8" (3 mm) from the right hand end of the header area,
leaving that last 1/8" uncolored, and the colored area shrinks when
there is an image, causing the image to be displayed against an
uncolored background.

>>> This fix suggests that on the laptop the proper node is not being
>>> found, so gets ignored. I agree, it's odd, but there are some 9X
>>> verses NT/XP differences that have been accommodated in the code.

That probably explains why my desktop (Windows ME, which is of
the 9X family) code doesn't work on my laptop (XP).

>>> That all goes away in the future with droppage of 9X support.

Not anytime soon, I hope.

>> Maybe so, apparently -moz-appearance settings cannot always be
>> overruled unless they are explicitly turned off, check:

>> #msgHeaderView {
>> -moz-appearance: none !important;
>> background-color: red !important;}

>> That works,

I had tried that before starting this thread, and it didn't work
for me.

>> on the other hand, 'deeper' nodes always seem to
>> overrule 'higher' nodes, check:

>> #expandedHeaderView,
>> #collapsedHeaderView {
>> background-color: red !important;}

That works the same way my original code works on the desktop, so
I've switched to that version.

>> or:

>> #msgHeaderViewDeck {
>> background-color: red !important;}

That doesn't work here.

>> or:

>> #msgHeaderViewDeck {
>> background-color: red !important;}
>> expandedfromBox {
>> background-color: lime !important;}
>> #expandeddateBox {
>> background-color: yellow !important;}

The only part of that that works here is the yellow in the date
box.

>> All work, the last one also changes the background color of some of
>> the lines (boxes) in the header.

Incidentally, my last four comments regarding working or not
working refer to the laptop. I've been away from home for more than a
week, so I haven't had a chance to test any of them on the desktop.

>> Michel.
> Yes, deeper nodes should override because they are closer to the
> element being styled. That is one of the basic rules of CSS. It is
> also likely the case for one of my past frustrations. I did not
> have DOMi at the time, so could not track down the line of CSS in
> the theme that had higher priority.

I've had DOMi installed for a couple of months now, but so far
have only a *VERY* rudimentary understanding of how to use it and what
it can do.

> Your last example is why the rule is nice to have.

dillinger

unread,
Sep 30, 2007, 4:26:32 PM9/30/07
to

Unfortunately I forgot a # somewhere up there :(
If you like colored lines, you could try something like this:

/* Headerbox colors */


#expandedHeaderView,
#collapsedHeaderView {
background-color: red !important;}

#expandedfromBox {
background-color: yellow !important;}
#expandeddateBox {
background-color: lime !important;}
#expandednewsgroupsBox {
background-color: cyan !important;}

You can also reduce the space taken by the headerbox by putting the
lines a little closer together:

/* Save some space */
.headerName {margin: 0 .5em 0 0 !important;}

Whether things work or not is of course also influenced by the theme
you're using, since a lot of theming works much in the same way.

Michel.

0 new messages