Closed Bug 39683 Opened 24 years ago Closed 20 years ago

Setting width of DIV in table dosn't reflow table

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.7alpha

People

(Reporter: sicking, Assigned: dbaron)

References

Details

(Keywords: css2, testcase, Whiteboard: block max width [patch])

Attachments

(2 files)

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...
Assignee: clayton → karnaze
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.
Assignee: karnaze → buster
Whiteboard: block max width
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → M18
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().
Priority: P2 → P1
[nsbeta3-]. Rare case. As a possible/partial workaround, is there any JavaScript 
method one can call to manually force a reflow?
Whiteboard: block max width → [nsbeta3-] block max width
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.
Target Milestone: M18 → Future
Keywords: nsbeta3mozilla1.0
Whiteboard: [nsbeta3-] block max width → block max width
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
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?
Keywords: mozilla1.0
Still occurs in the OS X 2002-07-31-05 build 
Over to block layout per comment 5
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: petersen → ian
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.
Assignee: core.layout.block-and-inline → dbaron
Whiteboard: block max width → block max width [patch]
Target Milestone: Future → mozilla1.7alpha
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.
Attachment #139806 - Flags: superreview?(roc)
Attachment #139806 - Flags: review?(roc)
*** 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
Attachment #139806 - Flags: superreview?(roc)
Attachment #139806 - Flags: superreview+
Attachment #139806 - Flags: review?(roc)
Attachment #139806 - Flags: review+
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.