39683 - Setting width of DIV in table dosn't reflow table

Status: VERIFIED FIXED

(Core :: Layout: Block and Inline, defect, P1)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If you set the width of a div which is inside a table using the .style.width 
attribute the table dosn't reflow correctly.

To reproduce:
1. Open testcase
2. move the mouse over the red square

This starts a script that sets the width of the div.

Expected result:
The div should get the width 100px causing the table to expand

Actual result:
The div expands but the table dosn't

Using build 2000-05-17-08 on Win98SE (but still think this is XP)

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: original testcase

Comment 2

[Nisheeth Ranjan]

Re-assigning bug to Chris...

Comment 3

[karnaze (gone)]

Buster, the cell's block is returning a max width during the incremental reflow 
equal to the width it returned during the initial reflow. Since the div got 
shorter, the max width should be less.

Comment 4

[buster]

do you mean max width, or max-element-size?

Comment 5

[buster]

This one is going to be hard. The extra space is coming from the difference 
between the real computed maxElementSize and the width of the block before the 
incremental reflow.  This space is being computed as right margin in 
nsBlockReflowContext::PlaceBlock().

Comment 6

[ekrock's old account (dead)]

[nsbeta3-]. Rare case. As a possible/partial workaround, is there any JavaScript 
method one can call to manually force a reflow?

Comment 7

[buster]

sorry, ek, no easy work around for this one.  it's not that the reflow isn't 
happening, it's that we're doing the computation wrong.

Comment 8

[buster]

this will not make NS6 RTM.  Milestone -> Future.

Comment 9

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

the behaviour of this bug has changed, but it's still not working. When the
width of the inner <div> is set the table actually *expands* instead of
shrinking to the right size.

Should this be reassigned to HTMLTables?

Comment 11

[Chris Petersen]

Still occurs in the OS X 2002-07-31-05 build 

Comment 12

[Boris Zbarsky [:bzbarsky]]

Over to block layout per comment 5

Comment 13

[Bernd]

cell 01313FA0 r=1 a=2232,UC c=2184,UC cnt=861
 block 01314014 r=1 a=2184,UC c=2184,UC cnt=862
  block 013142B8 r=1 incr. (Style) a=2184,UC c=1200,UC cnt=863
   text 01314338 r=3 a=UC,UC c=UC,UC cnt=864
   text 01314338 d=2160,228 me=252
   text 01314338 r=3 a=1200,UC c=UC,UC cnt=865
   text 01314338 d=1152,228 status=0x1
   text 012EAC50 r=0 a=1200,UC c=UC,UC pif=01314338 cnt=866
   text 012EAC50 d=1008,228 me=252
  block 013142B8 d=1272,552 me=1272 m=2184
 block 01314014 d=2184,552 me=1272 m=3096
cell 01313FA0 d=2232,600 me=1320 m=3144
The inner cell frame block reports the desiredsize as the old desiredsize back
and a even bigger max width

Comment 14

[David Baron :dbaron:]

It wouldn't surprise me if this is fixed by what I mentioned in bug 217369
comment 65.

Comment 15

[David Baron :dbaron:]

Attachment: patch

Comment 16

[David Baron :dbaron:]

Comment on attachment 139806 [details] [diff] [review]
patch

In the regression tests, this changed
table/marvin/table_overflow_td_dynamic_deactivate.html and maybe changed
table/marvin/table_overflow_td_dynamic_activate.html  These changes look fine
to me.

The basic idea of this patch is to do things consistently between the
out-of-line maximum width computation and an "unconstrained reflow".  There are
two changes:
 1. When a block has an explicit width (in the same cases where
max-element-width uses the explicit width), use the explicit width rather than
the content width

 2. account for margins the same way max-element-width calculation does (after
the patch for bug 217369), which will fix the same problem that happens there
for max-element-width for the maximum-width case.

Both changes are necessary to fix this bug.

Sorry for the low amount of context on the diff -- reducing the context was the
only way to get diff to generate something that I could separate from the patch
to bug 217369.

Comment 17

[David Baron :dbaron:]

*** Bug 228172 has been marked as a duplicate of this bug. ***

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 139806 [details] [diff] [review]
patch

+	     (eStyleUnit_Null != mStyleMargin->mMargin.GetLeftUnit())) {

Isn't this unnecessary? I thought null style values would lead to a computed
value of zero

Comment 19

[David Baron :dbaron:]

Well, the whole check is unnecessary since it can only be set to nonzero by this
code if it's coord or percent.

Comment 20

[David Baron :dbaron:]

Fix checked in to trunk, 2004-01-26 21:47 -0800.