[FIX]Textarea does not respect box model when max-width or max-height is applied to it

RESOLVED FIXED

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: eddy, Assigned: bz)

Tracking

unspecified
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)

If a textarea has a specified max-width or max-height, it will no longer respect the box model. Instead, the borders and the padding will also be counted in the width. This only happens in Firefox. IE, Opera, Chrome and Safari still respect the box model.

Reproducible: Always

Steps to Reproduce:
1.Create a textarea and give it a width, say 400px, with borders, say 4px wide and padding, say 10px.
2.Create an identical textarea under the first one, give it a max-width of 400px
Actual Results:  
The second textarea is 28px narrower than the first one, because the borders and padding are now counted in the width. The first textarea is 400px+8px+20px. The second one is 400px.

Expected Results:  
The second textarea should have the same width as the first one, 428px. It should still respect the box model.

I noticed this happens with any doctype and on any machine using any version of Mozilla Firefox (I used browsershots.org). Using -moz-box-sizing: content-box; does not help. Using border-box or padding-box makes things even worse. Specifying a value for rows or cols doesn't change anything. Also, I have only noticed this for textareas, div containers for example, will respect the box model fine with a specified max-width or max-height value. I haven't tried other elements like input.

This is important because many users might want to give a textarea a max-width and/or a max-height value in order to prevent browsers like Safari and Chrome from resizing the textarea. Since none of the other browsers have a problem with the box model, this is bad for the design as the textarea will look different in Firefox.
Have you also tested with the latest build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
If it is still reproducible, can you upload a testcase with the Add an attachment link?
(Reporter)

Comment 2

9 years ago
Created attachment 365233 [details]
Page showing textarea box model bug
(Reporter)

Comment 3

9 years ago
(In reply to comment #1)
> Have you also tested with the latest build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
> If it is still reproducible, can you upload a testcase with the Add an
> attachment link?

I have uploaded a page showing the bug. I have tested this with the latest release of Firefox (3.0.6) that I have and I uploaded a page to browsershots.org where I picked all versions possible of Firefox. The problem occurred on all of them. I also tested all versions of the other browsers and none of them had this problem, only Firefox.

Updated

9 years ago
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → style-system
(Reporter)

Updated

9 years ago
OS: Windows XP → All
(Reporter)

Comment 4

9 years ago
I just noticed that input elements behave in the same way. If a max-width or max-height is specified, they don't respect the box model any more.
(Reporter)

Comment 5

9 years ago
Any chance this will be fixed?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090313 Minefield/3.2a1pre

Confirming the described behavior.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.2?
(Reporter)

Comment 7

9 years ago
Just noticed the bug is this there in Fx3.0.8. I'm not really sure how Bugzilla works, is anyone working on fixing this issue, or do I have to do something? I appreciate your help.
(Reporter)

Comment 8

9 years ago
* "still there" not "this there"(In reply to comment #7)
> Just noticed the bug is this there in Fx3.0.8. I'm not really sure how Bugzilla
> works, is anyone working on fixing this issue, or do I have to do something? I
> appreciate your help.
Component: Style System (CSS) → Layout: Form Controls
QA Contact: style-system → layout.form-controls
The issue here is that text controls use nsStackFrame::Reflow as the reflow impl and that nsBoxFrame::Reflow applies min/max constraints to the border box, not the content box.

Does XUL in general rely on border-box sizing?  Or does it rely on width/height being content-box while max-width/height are border-box?  What about min-width/height?

I could probably work around this in the text control frame code by adjusting its max and min width/height in the reflow state before calling into the superclass, but it would be nice to sort out the XUL behavior too.
Created attachment 370218 [details]
with some additional testcases

The bug doesn't seem to show up with min-width.
Min-width affects the mComputedWidth in the reflow state (as does max-width, of course).  So when nsBoxFrame::Reflow compares

   mComputedWidth + mComputedBorderPadding.LeftRight()

to mComputedMinWidth, the former is always at least as big (since borderpadding is nonnegative, and mComputedWidth >= mComputedMinWidth).
(In reply to comment #9)
> Does XUL in general rely on border-box sizing?  Or does it rely on width/height
> being content-box while max-width/height are border-box?  What about
> min-width/height?
XUL is border-box all the way, I think.
So could we just stick "* { -moz-box-sizing: border-box; }" in xul.css and change nsBoxFrame::Reflow to actually check box-sizing?
Created attachment 370276 [details] [diff] [review]
Proposed fix

Basic idea is to set -moz-box-sizing for boxes and for the text inputs in chrome.  Then the reflow state will automatically compute the right computed wifth and height, so the only place where we have to do anything interesting here is the auto-height case.  For that, we use the results of GetPrefSize, but adjust for min/max height after taking the actual value of box-sizing into account.

Thoughts?
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #370276 - Flags: superreview?(dbaron)
Attachment #370276 - Flags: review?(dbaron)
Summary: Textarea does not respect box model when max-width or max-height is applied to it → [FIX]Textarea does not respect box model when max-width or max-height is applied to it
Seems reasonable to me.
(Reporter)

Comment 16

9 years ago
Great, so does that mean it will be fixed in the next release, 3.0.9?
3.0.9 is only getting security fixes or fixes for regressions from security fixes.

This is a pretty risky change, so I don't think it'll make 3.5 either.  It'll make the release after that, assuming the patch gets reviews and so forth.
Attachment #370276 - Flags: superreview?(dbaron)
Attachment #370276 - Flags: superreview+
Attachment #370276 - Flags: review?(dbaron)
Attachment #370276 - Flags: review+
Comment on attachment 370276 [details] [diff] [review]
Proposed fix

r+sr=dbaron

We might also want to have a bug on file for actually supporting other values of -moz-box-sizing in box frames...
Pushed http://hg.mozilla.org/mozilla-central/rev/607c4ad16edf

Filed bug 490359
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Flags: blocking1.9.2?
(Reporter)

Comment 20

9 years ago
Will this be fixed in 3.6?
Yes.  You could try a beta of 3.6 to check, you know...
(Reporter)

Comment 22

9 years ago
Ok, thanks!
You need to log in before you can comment on or make changes to this bug.