Closed Bug 325486 Opened 14 years ago Closed 13 years ago
Input element default value invisible when overflowing parent div
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060201 Firefox/1.6a1 If you place an input within an absolutly positioned div that is inside another positioned div (absolute or relative, does not matter) and the input element overflows the parent div, it's default value will get cut off until the user inputs some text. Reproducible: Always Steps to Reproduce: 1. See test case Actual Results: Input text gets cut off Expected Results: Input text should show
Having no luck uploading test case, added it to url section.
This is a regression between 28-Apr-2005.06 and 29-Apr-2005.06.
I guess this could be a regression from bug 240276.
Attaching testcase to the bug, so no chance of losing it.
Confirmed on OS X.
roc, any chance for looking at this for 1.9a1?
Assignee: nobody → roc
Since this looks to be a 1.8.1 regression - Roc can we get a fix in that branch?
Flags: blocking1.8.1? → blocking1.8.1+
Minusing for 1.8.1 blocking list, although we'd certainly still consider a patch.
Flags: blocking1.8.1+ → blocking1.8.1-
The problem appears to be that around here http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#2027 we set mComputedMaxWidth to something too small for the reflowState that BoxReflow is going to pass to the scrollframe0. We should not be doing this. I need to do more analysis to figure out what's wrong.
*** Bug 346192 has been marked as a duplicate of this bug. ***
According to the reflow state chain, the scrollframe's containing block is the innermost absolutely-positioned block. That innermost abs-pos block's reflow state has mComputedMaxWidth of 660, set by Mats' code here: http://lxr.mozilla.org/mozilla/source/layout/generic/nsAbsoluteContainingBlock.cpp#534 The scrollframe tries to honour this mComputedMaxWidth, which causes this problem. I'm not really sure what Mats' code is doing and it looks pretty fragile. I don't know why we are messing with the maximum width this way. A slightly less risky option would be to hack in around here: http://lxr.mozilla.org/mozilla/source/layout/generic/nsHTMLReflowState.cpp#2002 to go for intrinsic width for inline-block-like situations, of which this is one. I'll try that.
This fixes it. The idea is to treat block children of replaced elements (where the replaced element is inside the block child's containing block) as replaced, for the purposes of setting auto-width and height, i.e., force them to use intrinsic widths and heights.
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9] → [wanted-1.9][reflow-refactor]
The reflow branch fixes this, because we just compute the right intrinsic widths here.
fixed after reflow branch landing
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: reflow-refactor
Resolution: --- → FIXED
Comment on attachment 232661 [details] [diff] [review] fix minusing this patch since it's no longer needed now that the reflow branch has landed
Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.
The only difference between the test and the reference rendering is the width: 50px;/width: 500px;.
Attachment #258113 - Flags: review?(dbaron)
Attachment #258113 - Flags: review?(dbaron) → review+
Reftest checked in. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=reftest.list&branch=&root=/cvsroot&subdir=mozilla/layout/reftests/bugs&command=DIFF_FRAMESET&rev1=1.21&rev2=1.22
Flags: in-testsuite? → in-testsuite+
Whiteboard: [wanted-1.9][reflow-refactor] → [reflow-refactor]
You need to log in before you can comment on or make changes to this bug.