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

Status: RESOLVED FIXED

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

Description

[Shawn Neumann]

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.

Comment 1

[Shawn Neumann]

Attachment: Example of Layout strangeness

Comment 2

[Shawn Neumann]

I forgot to mention that I submitted this using MOzilla 1.2.1, but have found
the same issue in 1.3 and nightlies.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Shawn Neumann]

Attachment: 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.

Comment 5

[Shawn Neumann]

Attachment: And one more...

And this one has the table/cell width set to 300px.  A fixed rather than
relative amount.

Comment 6

[Shawn Neumann]

Also, all three of these attachments work in 1.0 and are broken in 1.2 (I
haven't tested 1.1)

Comment 7

[Bernd]

Attachment: testcase without bogus 100% width

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.

Comment 8

[Bernd]

To get rid of this one could probably extend the patch from bug 175455 to
include also margins (
http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsHTMLReflowState.cpp#2763)
. It may take several dozens of beer to convince me to ask dbaron for a review
of such a patch.

Comment 9

[Bernd]

Attachment: patch

Comment 10

[Bernd]

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

I had enough beers to ask for a review

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

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 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

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.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This should be fixed by bug 232754, right?

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

Since no one is saying this is still a problem, marking fixed.