Closed Bug 189367 Opened 18 years ago Closed 13 years ago

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


(Core :: Layout, defect)

Not set





(Reporter: coop, Unassigned)




(Keywords: testcase)


(5 files, 1 obsolete file)

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

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.
This is the same page as listed in the URL field, if you would like to download
and test locally.
Symptoms are similar to those listed in bug #162268.
Assignee: blaker → other
Component: General → Layout
Product: Phoenix → Browser
QA Contact: asa → ian
Version: unspecified → Trunk
Priority: -- → P3
Assignee: core.layout → nobody
Component: Layout → Layout: R & A Pos
Depends on: 201897
Keywords: testcase
QA Contact: ian → core.layout.r-and-a-pos
See it happening:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0
Assignee: nobody → mats.palmgren
Assignee: mats.palmgren → nobody
Ever confirmed: true
Component: Layout: R & A Pos → Layout
QA Contact: core.layout.r-and-a-pos → core.layout
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?
Depends on: 147558
Attached file 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
OS: Linux → All
Priority: P3 → --
Hardware: PC → All
Attached patch test patch (obsolete) — Splinter Review
The test patch is able to reflow all lines.
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.
Attached patch patchSplinter Review
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

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.
Attachment #183405 - Attachment is obsolete: true
Attachment #183583 - Flags: review?(bernd_mozilla)
Comment on attachment 183583 [details] [diff] [review]

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.
Attachment #183583 - Flags: review?(bernd_mozilla) → review-
s/this is/this patch is/
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.
Closed: 13 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.