Whenever a BoxToBlockAdaprot recieves an incremental reflow it does it inefficiently. 1) First it reflows the block at its intrinsic size to get the preferred size 2) It then reflows it back to its correct size. It should take advantange of the the blocks ability to compute max width during incremental reflow to get the correct size.

targeting

Sorry this took so long. Still going through this stuff (hey, I'm on vacation!), some first comments: - You're mangling some spaces in nsBoxFrame.cpp - nsBoxFrame::ReflowDirtyChild now marks all sibling boxes as dirty. How come? - Looks like _any_ attribute change is going to now dirty the box. Is this what you want? I'm applying the changes in my tree and will get back to you early next week. I swear! :-)

- You're mangling some spaces in nsBoxFrame.cpp Yep I'll see if I can't track them down! - nsBoxFrame::ReflowDirtyChild now marks all sibling boxes as dirty. How come? No, it only marks the child that requested a dirty reflow dirty and passes things back up. This wasn't happening before and caused lots of weird bugs where things weren't reflowed when they should be. - Looks like _any_ attribute change is going to now dirty the box. Is this what you want? Yes I believe this is what you want. Any attribute that gets to AttributeChanged should trigger a reflow. I think this is how it worked before I just moved some code around. But most attribute changes never call AttributeChanged. Only the ones specified in the content node. Thanks for looking a this. I'll be on vacation until friday the 30th. Let me know how the patch works for you.

sr=waterson. Heads up to kin and marc: this may fix some of those weird typing bugs.

Reproducing bug 98032 comment #10: I had a quick look at that patch and didn't see where the newly added nsBlockFrame::GetAscent() was called.

> Reproducing bug 98032 comment #10: > I had a quick look at that patch and didn't see where the newly added > nsBlockFrame::GetAscent() was called. layout/xul/base/src/nsSprocketLayout.cpp its in the patch.

Hey Eric, do you think your checkin could have caused Bug #113528? Around the same time as this checkin, outliner widgets started getting invalidated every time focus changes in a window. This is causing a non trivial performance regression for mail where we have 2 outliner widgets in the 3-pane. See David's comments in that bug as to why nsBoxFrame::ReflowDirtyChild is suddenly marking the outliner frames dirty when focus changes. This is causing more reflows now. Or that's our theory anyway.

fixed