428278 - Table outline rect grows when resizing the window

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Mats Palmgren (inactive)]

Spawned off from bug 427928

STEPS TO REPRODUCE
1. load the attached testcase
2. resize the window

ACTUAL RESULT
The red square (outline) expands slightly every time I resize
the window in any direction

EXPECTED RESULT
The red square stays the same size when resizing

PLATFORMS AND BUILDS TESTED
Bug occurs in Firefox trunk on Linux and MacOSX.
Bug does not occur in Firefox 2.0.0.13 on Linux.

ADDITIONAL INFORMATION
Running with -layoutdebug and dumping the frames before/after resizing:

before:
Table(table) ... [overflow=-180,-180,360,360]

after:
Table(table) ... [overflow=-4320,-4320,8640,8640]

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 2

[Mats Palmgren (inactive)]

Regression window: 20061207 -- 20061208 (reflow branch landing).

Comment 3

[Mats Palmgren (inactive)]

Attachment: reftest.diff

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

When we skip reflowing the children we use the old overflow rect as if it
were the child overflow rect, the problem is that it also includes the
outline (for example) for the table itself, so we end up accumulating an
outline for each reflow as long as we don't do a full child reflow.

This patch stores the child overflow rect on a frame property, but only
when it's really needed, ie when the table has overflow of its own,
so in most cases it will not be created.

Comment 5

[Bernd]

I am away for vacation will do after august 1th

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This patch will probably need updating for bug 439567.

Comment 7

[Bernd]

I do not really see why we need a second overflow rect just for tables the description of the bug seems pretty common. So why does this not happen in other circumstances?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Other frames always rebuild their overflow rect from their descendants when they are reflowed.  Tables could do that as well...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That said, tables normally have a pretty small number of children.  Why not just accumulate the overflow from the children when we skip reflowing them, like we do for other frames?

Comment 10

[Bernd]

Having less table specific stuff seems favorable to me. But don't we then need to descend into all children too?

Comment 11

[Mats Palmgren (inactive)]

Attachment: Patch rev. 2

As you suggested, this is simpler.
(we should only consider direct children since their overflow areas should
already contain deeper child overflow, or clipped it, as it may be)

Comment 12

[Bernd]

Comment on attachment 331993 [details] [diff] [review]
Patch rev. 2

this seems better to me

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 331993 [details] [diff] [review]
Patch rev. 2

sr=dbaron

Comment 15

[Mats Palmgren (inactive)]

http://hg.mozilla.org/mozilla-central/index.cgi/rev/3a1ac255e78d
http://hg.mozilla.org/mozilla-central/index.cgi/rev/12893191012a

-> FIXED

Comment 16

[Bill Gianopoulos [:WG9s]]

Could this have caused the tp regression that was discussed in bug 450401?

Comment 17

[Mats Palmgren (inactive)]

Seems unlikely.  I backed it out on the try server just in case and it
didn't seem to make a difference.  Also, the Tp regression bug 450401
appears to affect 1.9 branch too and this patch have not landed there yet.

Comment 18

[Daniel Veditz [:dveditz]]

Comment on attachment 331993 [details] [diff] [review]
Patch rev. 2

This does not appear to meet the branch criteria, we'll fix this minor cosmetic defect in 3.1