189367 - Form elements cause reflow in nested <div> with width less than 100%

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Chris Cooper [:coop] (he/him)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

 If you click on the <select> boxes or the submit or reset buttons on the
example page, the width of the <div> will gradually shrink as reflow events occur.

If you view the source of this page, you will see that there is a <div
class="entry"> with a width of 90% nested inside a <div class="main"> with
position=absolute. The reflow in question does not occur if:

    * position attribute is not set for <div class="main">
    * width=100% for <div class="entry">
    * there is not enough text inside <div class="entry"> that it requires line
wrapping


Reproducible: Always

Steps to Reproduce:
1.Click on <select> box or form buttons on affected page.

Actual Results:  
<div> is dynamically resized (get smaller) each time a new item is selected in
the <select> boxes, or the form buttons (submit or reset) are pressed.

Expected Results:  
No reflow should occur.

Comment 1

[Chris Cooper [:coop] (he/him)]

Attachment: HTML page that demonstrates the nested <div> reflow problem

This is the same page as listed in the URL field, if you would like to download
and test locally.

Comment 2

[Chris Cooper [:coop] (he/him)]

Symptoms are similar to those listed in bug #162268.

Comment 3

[Asa Dotzler [:asa]]

->layout

Comment 4

[Paul van Schayck]

See it happening:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0

Comment 5

[Mats Palmgren (inactive)]

The shrinking width part of the problem was fixed by bug 201897.
The remaining problem that form control elements move when you click on them is
reported elsewhere I think. Possibly bug 147558?

Comment 6

[Hideo Saito]

Attachment: simple testcase

In the simple testcase, the width of the <div> will shrink half as reflow
events occur, since the incremental reflow measures only a line of "ccccc
ddddd".

Comment 7

[Hideo Saito]

Attachment: test patch

The test patch is able to reflow all lines.

Comment 8

[Bernd]

Comment on attachment 183405 [details] [diff] [review]
test patch

This patch is so obviously wrong. How many times does a frame get a initial
reflow, as the word says initial => once. So what does the patch do? It simply
forces another unconstrained reflow by changing the reflowreason to initial.
The chances to get this reviewed are 0.

Comment 9

[Hideo Saito]

Attachment: patch

I mixed two patches that is 1. the changes for absolutely positioned frame with
'auto' width and 2. the changes for changing the line layout as reflow events
occur.

The changes for 1. causes to mark all lines dirty and the changes for 2. causes
to mark the previous line dirty. I think that the changes for 2. concerns with
Bug 92217.

Comment 10

[Hideo Saito]

Attachment: another testcase for patch

Comment 11

[Hideo Saito]

Attachment: screen shot for another testcase

Comment 12

[Bernd]

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

For me this patch is not better than the first one. It will mark lines dirty if
the parent has auto width.
The following is a repetition from a another review denial but it applies here
as well:
1. No hacks, please
2. I believe this is a hack, in order to convince me that this is not the case
please provide a reflow log and show where it goes wrong and how this patch
fixes the situation. Please pay special attention to the maximumWidth.

Looking at attachment 183402 [details], it probably first requests the maximumwidth and
sets that as the outerdiv width as it shrinks around the container. When the
link is focussed it wraps as it probably uses the previous width instead of the
maximumwidth. This patch reinforces a new maximumwidth computation by marking
all lines dirty. 

However I am not a block specialist like roc or dbaron are but I am pretty
confident that this is wrong.

Comment 13

[Bernd]

s/this is/this patch is/

Comment 14

[Hideo Saito]

This problem is already fixed from build of seamonkey-1.5a-20061208-trunk/WinXP and later, I think this is fixed by the fix for Bug 300030.