Right now we create and destroy space managers during each reflow (for every frame that could possibly need a space manager). This leads to O(N^2) state recovery for an incremental reflow. This seems complicated to fix, but some thoughts on how it could be done are: * store the frame that would have the space manager in the reflow state rather than (or in addition to) the space manager itself, and store the space manager for the lifetime of the frame tree as a property of the frame, but only for frames that actually contain floats. * (the hard part, perhaps) Keep the space manager updated when things change between reflows

Note that the float damage stored by the space manager (see bug 86947) must be cleared each reflow, or perhaps maintained separately from the space manager.

This one has a huge impact on performance (just see the dependency-tree).

Why do you say it's huge? My memory is that it's one of the smaller of the remaining O(N^2) issues with loading long pages incrementally.

Well, you know this best. Which are the big killers (bugs) you'd say?

adt: nsbeta1-

Moving to p3 because no activity for at least 2 years. See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information