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

RESOLVED FIXED in Firefox 42

Status

()

RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jfkthame, Assigned: jfkthame)

Tracking

(Blocks: 2 bugs)

unspecified
mozilla42
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
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.
(Assignee)

Comment 1

3 years ago
Created attachment 8627156 [details] [diff] [review]
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.)
Attachment #8627156 - Flags: review?(dholbert)
(Assignee)

Updated

3 years ago
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
Last Resolved: 3 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.