Closed Bug 271927 Opened 15 years ago Closed 13 years ago
Absolute Containing Block::Incremental Reflow calls Reflow Absolute Frame twice
nsAbsoluteContainingBlock::IncrementalReflow calls ReflowAbsoluteFrame twice. This bug is followup from bug 201897: ------- Additional Comment #31 From Mats Palmgren 2004-10-03 18:00 PDT A note on the existing code: I'm surprised that nsAbsoluteContainingBlock::ReflowAbsoluteFrame is called twice for every nsAbsoluteContainingBlock::IncrementalReflow (which means we will reflow shrink-to-fit boxes four times). Is there a reason for this? ------- Additional Comment #33 From Boris Zbarsky 2004-10-03 18:16 PDT > I'm surprised that nsAbsoluteContainingBlock::ReflowAbsoluteFrame > is called twice The first call is because we have a reflow command for the absolute list (reflows all dirty absolute frames) and the second is because the reflow path contains one of our child frames, right? Could we flip those two chunks around? Presumably any frames we flow because they're in the reflow path would get marked clean after the reflow and we wouldn't flow them twice? Would that screw up the eReflowReason_Initial twiddling in the dirty block, though? Alternately, could we prune frames we reflow because they're dirty from the path so that they're ignored in the second block?
roc, any thoughts on this?
Not off the top of my head. What you suggest should be workable.
This code went away with the reflow branch. The new code doesn't have this problem.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.