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

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Jonathan Kew [:jfkthame]]

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.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Don't call ConsiderChildOverflow until the child has been placed in the right location when reflowing a vertical-rl table

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.)

Comment 2

[Daniel Holbert [:dholbert]]

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.

Comment 3

[Daniel Holbert [:dholbert]]

Oh, I missed the removal from ReflowChildren at first.  So we were doing this unconditionally already, effectively.

Comment 4

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3524973b9630

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/3524973b9630