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

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[eddy]

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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

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?

Comment 2

[eddy]

Attachment: Page showing textarea box model bug

Comment 3

[eddy]

(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.

Comment 4

[eddy]

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.

Comment 5

[eddy]

Any chance this will be fixed?

Comment 6

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090313 Minefield/3.2a1pre

Confirming the described behavior.

Comment 7

[eddy]

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.

Comment 8

[eddy]

* "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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: with some additional testcases

The bug doesn't seem to show up with min-width.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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).

Comment 12

[[e-mail]]

(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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

So could we just stick "* { -moz-box-sizing: border-box; }" in xul.css and change nsBoxFrame::Reflow to actually check box-sizing?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: 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?

Comment 15

[[e-mail]]

Seems reasonable to me.

Comment 16

[eddy]

Great, so does that mean it will be fixed in the next release, 3.0.9?

Comment 17

[Boris Zbarsky [:bzbarsky]]

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.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 19

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/607c4ad16edf

Filed bug 490359

Comment 20

[eddy]

Will this be fixed in 3.6?

Comment 21

[Boris Zbarsky [:bzbarsky]]

Yes.  You could try a beta of 3.6 to check, you know...

Comment 22

[eddy]

Ok, thanks!