Having to supply several images with the different states for every icon is cumbersome. Getting these states wrong is easy (see e.g. bug 431627), and most extension authors don't even bother to ship different icon states for their toolbarbuttons. Instead we should just implement the color changes using SVG filters directly in the toolkit theme.

There are still three challenges I'm having: 1. How to preload the external filter file. I don't want the button to flash the first time it's clicked. 2. How not to affect Txul. E.g. the stop / refresh buttons on windows would get grayed out by a filter when they're disabled, and those buttons are in the default set of the main browser toolbar, so they could definitely affect Txul. 3. How to make this work for XUL in content. Right now I'm getting a security error, which is probably the same as bug 462014.

I've talked to Boris; point 3 is pretty much blocked on bug 462014, and that isn't likely to get fixed in the 1.9.2 timeframe. So this will have to wait a bit.

(In reply to comment #2) > I've talked to Boris; point 3 is pretty much blocked on bug 462014, and that > isn't likely to get fixed in the 1.9.2 timeframe. So this will have to wait a > bit. It could be done in browser/themes/ without bug 462014, though.

Huh? Problem 3 is that http://*.xul can't use filters living in chrome://*. If we don't care about XUL-in-content users, we could still do it, of course. The only problem is that when these filters are blocked, the filtered elements disappear completely, instead of just showing the original unfiltered image...

Remote XUL isn't going to use browser/themes/.../browser.css.

Ah, I see.

If we still want to do this, we should probably use CSS filters instead (which will be supported soon), since those sidestep all of the problems from comment 1.