Setting width of DIV in table dosn't reflow table

VERIFIED FIXED in mozilla1.7alpha



19 years ago
15 years ago


(Reporter: sicking, Assigned: dbaron)


({css2, testcase})

css2, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: block max width [patch])


(2 attachments)

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)
Keywords: testcase

Comment 2

19 years ago
Re-assigning bug to Chris...
Assignee: clayton → karnaze

Comment 3

19 years ago
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


19 years ago
Priority: P3 → P2
Target Milestone: --- → M18

Comment 4

19 years ago
do you mean max width, or max-element-size?

Comment 5

19 years ago
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 


19 years ago
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

Comment 7

19 years ago
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

18 years ago
this will not make NS6 RTM.  Milestone -> Future.
Target Milestone: M18 → Future
Keywords: nsbeta3 → mozilla1.0
Whiteboard: [nsbeta3-] block max width → block max width
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
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

Comment 11

17 years ago
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

Comment 13

15 years ago
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
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]

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)
Comment on attachment 139806 [details] [diff] [review]

+	     (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.
Last Resolved: 15 years ago
Resolution: --- → FIXED


15 years ago
You need to log in before you can comment on or make changes to this bug.