Closed Bug 198283 Opened 21 years ago Closed 20 years ago

[FIX] Divs within a td get redrawn with growing width then the divs contain a margin value


(Core :: Layout: Tables, defect, P3)

Windows 2000





(Reporter: info, Unassigned)



(Keywords: testcase)


(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

I will upload an HTML attachment that demonstrates the situation.  The HTML
demonstrates a table with a div inside.  This div has a margin-left value of
25px.  Inside the main div is both a form and another div set to width=100%. 
When you interact with the form (in this case a select box) within a <div> that
is within a <td>, the divs inside the with a width of 100% grow by the value of
the margin (25px).

Reproducible: Always

Steps to Reproduce:
choose a different select box option in the drop down.
Actual Results:  
The containing div will grow by the size of the "margin-left" css value each
time you select a new item from the select box.

Expected Results:  
The div size should remain constant whe interacting with the form.

This is causing strangly unstable interfaces in some of our web based systems.
Severity: normal → major
I forgot to mention that I submitted this using MOzilla 1.2.1, but have found
the same issue in 1.3 and nightlies.
Your CSS asks mozilla to solve the following system of equations:

cell_width = div_width + 1px(border) + 25px(margin);  (cell width determination)
div_width = cell_width (100% in the CSS).

There is no solution, so weird shit happens.

This is a duplicate....
Whiteboard: DUPEME
Attached file Another Case
The equation you mentioned is not necessary to get this behaviour.  This is an
attachment where the cell width is defined "100%" and the behavor persists.
Attached file And one more...
And this one has the table/cell width set to 300px.  A fixed rather than
relative amount.
Also, all three of these attachments work in 1.0 and are broken in 1.2 (I
haven't tested 1.1)
I believe the 100% on the divs are not necessary, thats exactly what width:auto
is for on blocks. 100% widths are necesarry for tables as there auto width
shrink wraps the content.
To get rid of this one could probably extend the patch from bug 175455 to
include also margins (
. It may take several dozens of beer to convince me to ask dbaron for a review
of such a patch.
Attached patch patchSplinter Review
Ever confirmed: true
Summary: Divs within a td get redrawn with growing width then the divs contain a margin value → [FIX] Divs within a td get redrawn with growing width then the divs contain a margin value
Keywords: testcase
Priority: -- → P3
Target Milestone: --- → Future
Comment on attachment 117870 [details] [diff] [review]

I had enough beers to ask for a review
Attachment #117870 - Flags: review?(dbaron)
Comment on attachment 117870 [details] [diff] [review]

It seems simpler to have

nscoord availableContentWidth = availableWidth - ... - ...;
and then use only mComputedWidth and availableContentWidth for the rest.

However, I still want to understand what this is trying to do...
Comment on attachment 117870 [details] [diff] [review]

Since we have this code in here, it can't hurt to make it "right", so
r+sr=dbaron if you fix it according to my previous comment.

However, I think the patch in bug 175455 is basically wrong and should
disappear when we switch to a reasonable method of computing min/max widths.
Attachment #117870 - Flags: review?(dbaron) → review-
Depends on: 232754
This should be fixed by bug 232754, right?
Yes, as far as I can tell.  The problem description in this bug is so vague,
though, that I'm not sure I understood it correctly...
Since no one is saying this is still a problem, marking fixed.
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.