103168 - need a way to serialize userChrome.css and write it back out

Status: RESOLVED WONTFIX

(Core :: General, defect)

Description

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

need a way to serialize userChrome.css and write it back out

we'd need this feature for our labels feature.

the user would be able to change the colors for labels, which would affect the
thread pane.  the users changes to userChrome.css would override the defaults in
threadPane.css

according to hyatt, there is already a way to manipulate userChrome.css in
memory, we'd need to figure out how to do that, too.

Comment 1

[David Hyatt]

While this would kick ass, this is very very *very* hard.

Keep in mind that manipulating a stylesheet in-memory is preposterously
expensive and results in your entire frame tree being torn down and
reconstructed (i.e., expect it to take seconds to make a change to the user
stylesheet).  

Also, the user stylesheet is not just used by mailnews.  It is used by every
single chrome window, which means that changing this stylesheet will behave
exactly like a dynamic skin switch, which was turned off because of its many
many problems.

This warrants a lot of consideration before actually trying to write code.

Comment 2

[Scott MacGregor]

Dave what if we did the usual "your changes will take effect the next time you
restart mozilla"? Then we can write out the changes to user.css at shutdown or
something. Thereby bypassing the expensive cost of tearing down our frame trees. 

Comment 3

[David Hyatt]

A IMO much simpler solution is to just store this in prefs, and then manually
alter threadPane.css in memory to add the rules (based off the pref values)
right after the stylesheet loads (but before it is attached).

Comment 4

[Alec Flett]

one idea, which I'll throw out there just for --- and giggles is RDF templates
in CSS. Just like RDF templates can be used to generate XUL content, why not
have a mechanism by which we could generate CSS rules via RDF?
Then, the user colors could just be stored in some RDF datasource which you
could manipulate at runtime. Poking assertions into the datasource would only
change/create rules within stylesheets have templates that reference it, so that
mail could poke at their color prefs without affecting every XUL document
loaded.
Anyway, blue sky..

Comment 5

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

> A IMO much simpler solution is to just store this in prefs, and then manually
> alter threadPane.css in memory to add the rules (based off the pref values)
> right after the stylesheet loads (but before it is attached).

what if the pref values change after it is attached?  (say, they toggle prefs
after the 3 pane is up.)

worst case:  we could make the label color changing feature one that only takes
affect after restart.

Comment 6

[David Hyatt]

Don't try to do it live.  Make it a change that requires a restart.

Comment 7

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

wacky idea:

in our threadPane.css we define 15 rules, red, blue, green, etc, and in the 
prefs the user sets up which one they want of the 15.

(instead of the color picker, we'd need a special picker / menulist)

then, when we return the cell properties, we return one of the 15 colors, based 
on the user prefs, like "label-color-red"

a sample idea for threadPane.css:

outlinerbody:-moz-outliner-cell-text(label-color-red) {
  color: red;
}

Comment 8

[David Hyatt]

Yes, that would be even easier and faster too.

Comment 9

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

that would allow us to do a live change of color, but it would limit us to the 
hard coded colors (advanced users could add more to userChrome.css).

it would also mean more rules in threadPane.css, would that be a perf hit?

best case, it's not a big hit, and we do 70 rules, to match the current color 
picker.

Comment 10

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

if it is a big hit, we do less (15?) and have a different picker for label 
color.

Comment 11

[Ben Bucksch (:BenB)]

Maybe you can create a new stylesheet just for label colors and reference that
in threadPane.css. You could write that file using normal file-writing routines
(no need to worry about overwriting). You could allow arbitary colors.
Disadvantage: Depending on how Gecko works and which features it offers, you
might have to restart before the change takes effect. (But maybe Gecko doesn't
cache CSS files and you can ask it to redraw the thread pane, in which case a
restart shouldn't be necessary.)

Comment 12

[scottputterman]

It doesn't sound like we need this anymore for labels so I'm removing the
dependency.

Comment 13

[Wayne Mery (:wsmwk)]

still valid?

Comment 14

[Mike Conca [:mconca]]

(In reply to Wayne Mery (:wsmwk) from comment #13)

still valid?

No.