204312 - Offsetwidth for tr element returns enormous value if its table is absolutely positioned and is within an absolutely positioned element.

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Timothy Humphrey]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

The test case page demonstrates the bug.  The first alert should not report the
width of the table row as 71 million; the second alert is correct.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Timothy Humphrey]

Attachment: Testcase for bug

Comment 2

[Boris Zbarsky [:bzbarsky]]

Actaully, that _is_ how wide the <tr> is, if you look at it in DOM inspector. 
So this may be a layout bug, but certainly not a DOM one....

Comment 3

[Bernd]

71582792 * 15 = 1073741880 = 0x40000038 -> Somebody is doing arithmethics with
an unconstrained size. For those of you who cant wait to fix the bug,
Here are the steps to debug: first identify what name the variable offset.width
has internally it should be part of the reflowstate, second look for the
unconstrained size arithmetics, they should NEVER happen.

Comment 4

[Bernd]

This is not a table bug! Unconstrained resize reflows should NEVER be issued on
a table. 

   area 025D068C r=2 a=9180,UC c=UC,UC cnt=873
    tblO 025D0924 r=2 a=UC,UC c=0,0 cnt=874
    tblO 025D0924 d=885,570 o=(0,0) UC x 570
   area 025D068C d=0,0 o=(120,1200) UC x 570

The bug here is that abs pos blocks dont play by the rules, they issue a
unconstrained initial reflow and then should issue a constrained resize reflow
but they do not.
 

Comment 5

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

ok, ->r&a pos

Comment 6

[Mats Palmgren (inactive)]

The numbers in the testcase looks good to me.

-> FIXED (by bug 201897)