Closed Bug 1178250 Opened 6 years ago Closed 6 years ago

tables in vertical-rl mode may get an excessive overflow area

Categories

(Core :: Layout: Tables, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
firefox42 --- fixed

People

(Reporter: jfkthame, Assigned: jfkthame)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

When reflowing a vertical-rl table, we shouldn't call ConsiderChildOverflow on child frames that haven't yet been put in their correct positions because we're using a "fake" containerWidth of zero and planning to fix up the positions later.

This shows up as a large negative-x overflow area when inspecting the frame tree, and enabling paint flashing makes it obvious that we're often painting more than we need to.
This makes things a lot better, and eliminates lots of redundant painting. (I suspect there are more cases like this, but this fixes the main nsTableFrame one, at least.)
Attachment #8627156 - Flags: review?(dholbert)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
So, this switches us from doing this in an "if ([stuff's dirty) {...} else {" clause, to doing it unconditionally. Is that bad?

Seems like it might be better to change the "else" clause to "else if (!fixupKidPositions) {", to restrict the existing code to not run for vertical-rl tables -- and then add a new dedicated copy of the 1-line ConsiderChildOverflow loop inside of the existing "if (fixupKidPositions)" clause.
Oh, I missed the removal from ReflowChildren at first.  So we were doing this unconditionally already, effectively.
Attachment #8627156 - Flags: review?(dholbert) → review+
https://hg.mozilla.org/mozilla-central/rev/3524973b9630
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.