Dynamic opacity changes that return a FRAMECHANGE instead of just a VISUAL hint do not work. This fails even if the change does not _need_ FRAMECHANGE (just making ComputeChangeHint() in the CSS parser return a FRAMECHANGE hint for opacity changes all the time will make this _very_ clear).

Ok. For me the problem is much, much bigger than You think. Most of my conclusions i told Boris yesterday, but i'll repeat them now. I will split whole problem into parts, but i dont see any reason to report each bug alone. I also recommend description change. For easier writing i'll use here "sequences". To test it, just set following values in right order (for example here: http://alladyn.art.pl/gandalf/MozillaTests/problem.html ) 1) Bug with "1" value. Try set this sequence: 0.5,1,0.7,0.4 . Result is strange. Layer will get Opacity 0,5 then lock for next 2 values, and then will get 0,4. 0.5,LOCK,LOCK,0,4 For me reason is here: http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsCSSParser.cpp#3339 First, we set Opacity to 0.5 - everything works correct. After this, we change it to 1.0 . Mozilla checks if OldValue (0.5) and new one (1.0) are equal. For some reason the anwser is 'yes'. Mozilla sets '1.0' as OldValue, but dont repaint anything. Then we set Opacity=0.7 . And the same situation. Mozilla compares if oldValue (1.0) and new one (0.7) are equal. They are indeed. (but oldValue becomes 0.7). And the last value. '0.4'. When we set this, mozilla compares oldValue(0.7) and the new one (0.4) and the result is false, so its repainted. Meaby i'm wrong, but i see it like this. 2) Problem with Percent changes. Every time when sequence has percent value (like '20%') it locks futhur changes. I cannot get any reason for this. Try this sequence - 0.6,'20%',0.8,0.9 . The only thing i knowis that here exists the same problem. For some reason, setting percent locks it, and next change wont appear (but after it all goes right - 0.9 appears). Probably its the same reason - something with comparing values (like '1' in first). 3) problem with background/color CSS styles. If any of them are set layer dont repaint after opacity changes. Huh. Thats all. I hope that first 2 problems has the same reason and can be fixed together. I dont get problem with third, and hope You'll find reason :) And i hope dbaron wont say that, we should remove opacity from Mozilla. It wont be good, and it'll make Mozilla "weaker". Greets

Update. But 1 is propertly described by bz in comment #1. NS_STYLE_HINT_FRAMECHANGE is returned, but nothing happens. To check this try set 1 to mozOpacity - hanged, try set 1.1 - not hanged, and change executed. Probably, when we'll fix bug with 1.0 we'll probably need to change nsCSSParser.cpp line 3357 - if (aOldValue.GetFloatValue() == 1.0 || aValue.GetFloatValue() == 1.0) { + if (aOldValue.GetFloatValue() >= 1.0 || aValue.GetFloatValue() >= 1.0) {

This now worksforme...

WFM too. When it was fixed???

I don't know, and I don't really care enough to dig.