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)

Re-assigning bug to Chris...

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.

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

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

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

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.

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

Build reassigning Buster's bugs to Marc.

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?

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

Over to block layout per comment 5

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

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

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.

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

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

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

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