Closed Bug 107873 Opened 23 years ago Closed 21 years ago

input text box parent resizes unexpectedly with long input

Categories

(Core :: Layout: Block and Inline, defect, P1)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 215857
Milestone:
Future

People

(Reporter: zak, Assigned: dbaron)

References

Details

(Whiteboard: [reflow-refactoring][patch])

Attachments

(4 files, 3 obsolete files)

Reporter's testcase to facilitate bug reproduction
1.03 KB, text/html
Details
sample testcase
1.28 KB, text/html
Details
slightly cleaner version of previous patch (the cleaner one this time, really)
2.27 KB, patch
Details | Diff | Splinter Review
test case for the patch
793 bytes, text/html
Details 
Under certain circumstances, specifically a text input box within a div with
margins left and right set to auto and width set to 100% which is itself within
a div and these are in a table, when entering text into the input box, the
column around the input box resizes itself  when input is entered into the input
field. What should happen is the text scroll off to the right and no resizing
happen.

I am going to paste a bit of code here. I hope this is appropriate. It
duplicates the precise problem.
<html>
<head>
<style type="text/css">
div.sidebox
{ padding: 0px; align: center; border-width: 1px; border-style: dotted;
border-color: #003366; margin-left: auto; margin-right: auto; text-align: center; }
div.boxtext
{ width: 100%; border-width: 1px; border-color: #003366; border-style: solid;
border-top-width: 0px; margin-left: auto; margin-right: auto; background:
#ffffff; padding: 0px; }
</style>
<title>
Carfolio.com: The most comprehensive online car specifications database in the
world. 
</title>
</head>
<body marginwidth="0" marginheight="0">
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td class="greybg" valign="top" style="padding: 2px;" width="200">
<div class="sidebox" style="background: #336699;">
<div class="boxtext">
<form action="/search/results/" method="GET">
<p>
<input type="text" name="terms" value="search" size="12" />
</p>
<p>
<input type="submit" value="Go" />
</p>
</form>
</div>
</div>
</td>
<td bgcolor="#ffffff">
&nbsp;
</td>
</tr>
</table>

</body>
</html>
Confirming on 20011113/Win98, using reporter's testcase. Marking as NEW and
Platform->All since it affects at least Win32 and Linux.
It seems that the issue indeed is caused by the nested DIV section, when its
style specifies AUTO for both margin-left and margin-right properties. Textarea
width is increased everytime a character is typed or deleted. IE does not show
this problem. Related CSS1 recomendation (regarding to margin- properties and
calculation of overall width) can be found at
http://www.w3.org/TR/REC-CSS1#horizontal-formatting.
Assignee: asa → alexsavulov
Status: UNCONFIRMED → NEW
Component: Browser-General → Form Submission
Ever confirmed: true
OS: Linux → All
QA Contact: doronr → vladimire
not form submission, layout

DEMO:

open the testcase, LBUTTONDON(mouse) on the button (Go) then move the mouse
pointer over the button (while keeping the left mouse button pressed) and you'll
see the same thing happen. Incremental reflow issue. Bet it has to do with the 
margin-left/right: auto style.
Component: Form Submission → Layout
QA Contact: vladimire → petersen
Attached file sample testcase — 
thie test case demostrates the problem:

in case of a block with procentage width the computed width (in the
aReflowState) is calculated by its containing block including margins, borders,
paddings left/right in the resize reflow. then the block uses this computed
width and ads again the margins, borders, paddings. it has to be repaired in
the nsHTMLReflowState::ComputeBlockBoxData be cause that's the place where the
computed width gets calculated. (have patch)
Attached file proposed patch (obsolete) — 
the patch adds the substraction of the margins, paddings, borders from the
computed width in the method:

nsHTMLReflowState::ComputeBlockBoxData

Explanation:

      ComputeHorizontalValue(aContainingBlockWidth, aWidthUnit,
			     mStylePosition->mWidth, mComputedWidth);

sets mComputedWidth to the size of the content of the containing block
calculated in the initial reflow. E.g. in case of a 100% width this will be
exactly the content width.
But the block that is going to be reflowed is adding again the margins,
paddings, borders in the method:

nsBlockFrame::ComputeFinalSize
...
  if (!HaveAutoWidth(aReflowState)) {
    aMetrics.width = borderPadding.left + aReflowState.mComputedWidth +
      borderPadding.right;

So we have to substract this from the computed width that's going to be passed
to the Reflow method.
Regarding the patch: 
0) so, this makes the computedWidth not include the border, padding and margin
for the initial reflow case, and that matches the incremental reflow case, right?
1) have you successfully run the regression tests? 
2) don't we need to check for mComputedWidth going negative with all of that
subtraction? Since you assert in your comment in this bug that the
mComputedWidth will include the margin and border/padding, it should not go
below zero, so I would put an assertion.
3) Comment the code: explain why this is being done, but number etc.

Assuming that (1) has been done, and that you address (3) and optionally (2),
sr=attinasi
ok let's wait for dbaron... 

This seems like the wrong solution.  The basic problem here is one that we have
run into before -- a percentage-based outer-width greater than 100% causes
growth on incremental reflow.  We need to be very consistent that
percentage-based numbers are always based on the parent width computed in the
first-pass (or next-to-last-pass, if there are more than 2 passes in the
algorithm) reflow.

Am I correct that we would have the same problem if you gave 'width: 110%' with
no padding and border, and that this patch wouldn't fix that problem?
(And I'm not sure exactly how we would want to go about doing what I mentioned
above.)
Er, wait.  I think this is actually a table problem.  The key is that the table
is an element that sizes to its content.  This means it has to be consistent in
sending the same width to the content every time it reflows.  One way to fix
that would be to prevent the table cell from growing after the second-pass
reflow of a percentage-width child, which I would think is the right thing to do
anyway (although do any web pages depend on our current behavior?).  That is, if
you specify 'width: 110%' on a block that's inside a table cell, the table cell
would be sized as if the block had 'width: auto' and then the block would be
110% that size.
... although that problem could itself be a block problem.  It could be that
there's a bug with the BRS_COMPUTEMAXELEMENTSIZE calculations for blocks that
have percentage widths.
is not only a table problem... the sample test case has a testcase without a table.

but I agree. i don't like the ideea of substracting and readding the margins,
borders, padding. but then the change I have to do to the block code will be a
difficult one. 

ok... let's say the proposed patch (attachment 59612 [details]) is only a hint.
working on a new patch.
david:

the problem with the 110% widths seems to be another one:
(is there even without the patch)

let's say we have a 110% width div in a div in a table.

<table><tr><td>
 <div id="A">
  <div id="B" style="width: 110%; border: 8px;">
   <img width="100" ...>
  </div>
 </div>
</td></tr></table>

In the initial reflow the only known values are image width and the viewport
width.  So the first to know its width is block B that wants to be 100 + 8.
Then block A is adding its border,padding and margin of B (all null so we don't 
care) and wants to be 108. The cell block will shrink to that value.

In the next resize reflow the block A will get 108 as available and its computed
width will be also 108. When block A reflows bock B in

nsBlockReflowContext::ReflowBlock

the normalReflowState will be initialized with a computed width that is 110% of
108. That hapens in

nsHTMLReflowState::ComputeBlockBoxData
...
      ComputeHorizontalValue(aContainingBlockWidth, aWidthUnit,
                             mStylePosition->mWidth, mComputedWidth);


So block B will become 128 as computed width. Now if I don't apply the patch in
ComputeFinalSize block B will add the border and padding again and it will become
144 wide. 

Whether i apply the patch or not the problem lays in the nature of the situation:
how to calculate 110% of unknown? (IE fails here and if the % width is < 100 it
will be ignored.) 
We determine the width of the content of block A in the first pass, then we
resize the content (bock B) to be 110% of it's own size without resizing the
containing block B afterwards.
Even if the containing block of block A has a width (just remove the table from
this example so that the divs are contained directly in the body), we still have
the problem that the contained block B will be bigger than the containing block A. 
I think a solution would be to handle all % widths > 100% as 100% and all that
are < 100% to be honoured unless the resulting width is smaller than the width
of the content (the image in our case).

The above patch fixes what was actually a pretty major underlying flaw in the
block code -- that it was reporting a different max-element-size on a later
reflow than it was on the first.  (Have there been workarounds in the table code
to prevent this from showing up as a more serious problem?)
Well, actually, there are some test cases I can think of that this patch might
hurt -- a percentage width element with width greater than 100% inside of a
fixed width element inside of a table cell.  The way I'd expect that to be
displayed is width the oversized element sticking out of the table cell, but I'm
not sure whether that's how our table code will handle it.  I'll have to test to
see what it does...
I apply the latest patch and still have problem with this testcase.
Check it out, don't forget to click on the image.

(there is a slight possibility that I made a mistake while applying the patch)
God... as soon as you try here to change something, you break 1000 other things...
just default complaining :-)
Blocks: 115688
setting milestone
Target Milestone: --- → mozilla1.1
Attachment #59782 - Flags: needs-work+
*** Bug 127350 has been marked as a duplicate of this bug. ***
Attachment #59612 - Attachment is obsolete: true
Tested with 2002071508/Win2K and found that the original testcase (1st
attachment) is working as expected (no resizing noticed). I can't use the rest
of testcases (images don't work). Please verify if it's really wfm now.
Component: Layout → Layout: Form Controls
QA Contact: petersen → tpreston
Whiteboard: [reflow-refactoring]
yeah, the resizing issue is gone. i guess we could close this bug.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
The resizing issue is not visible in the testcase anymore because text inputs
are now reflow roots, so there's no reflow happening where it used to.

Reopening.  Trivial steps to reproduce are:

 * load attachment 59608 [details]
 * enter
javascript:void(document.getElementsByTagName("input").item(0).style.textIndent
= "0.1px")
   in the URL bar (varying the size each time between 0.1px and 0)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Taking bug
Assignee: alexsavulov → dbaron
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Component: Layout: Form Controls → Layout: Block & Inline
Priority: -- → P1
Target Milestone: mozilla1.1alpha → Future
Whiteboard: [reflow-refactoring] → [reflow-refactoring][patch]
I rewrote roughly the same patch on another bug.

*** This bug has been marked as a duplicate of 215857 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: