See bug 377419 comment 38. Any time we have any kind of painting performance issue, this absolutely kills us, as we discovered in that bug. Case in point: changing the value of any combobox on pretty much any Bugzilla page is really slow. Ideally, we wouldn't be invalidating the world that way, but only invalidating the things that actually changed...

I tested the issue in bug 91491, and it's not a problem with this patch: it got fixed by bug 379353. I think this should be safe change to make; I did some testing and didn't run into any bugs. Note that the only substantive change is the one in nsTableFrame::Reflow. The rest is non-behavior-changing cleanup that just makes it more obvious that we always do that invalidate.

Comment on attachment 301563 [details] [diff] [review] Let's just do this Requesting approval. This is probably low-to-medium-risk, but is a nice performance win on DHTML-like stuff in many situations. In the unlikely event that this turns out to have too many regressions, it'll be easy to just put the over-invalidation back in as late in the cycle as we want. So I think there's not that much risk to taking this patch.

Checked in.

It's quite likely this caused bug 416073

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020702 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) V.Fixed, per bug 377419 comment 54 ... [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008020803 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) ... and regression bug 419073 too :-)

(In reply to comment #5) > ... and regression bug 419073 too :-) s/bug 419073/bug 416073/.