388086 - [FIXr]fixed-width textarea and cols gets horizontal scrollbar

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Go into the URL testcase, and add a few newlines to the end of the line -- when the vertical scrollbar appears, a horizontal one does as well, seemingly for a 1px overflow.  bz looked into it briefly, and wasn't sure what was causing it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So what I see for that scrollable div in the textarea is something like:

Area(div)(-1)@0x25b15d0 [view=0x3cff99a0] {0,0,2340,3744} [state=00c06018] [overflow=0,0,2400,3744] sc=0x25b1550(i=4,b=0) pst=:-moz-scrolled-content<
  line 0x25b16c8: count=2 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:linebr[0x4880] {60,0,2340,936} <
    Text(0)@0x259b01c[0,5,T]  next=0x25ac8ec {60,77,2340,781} [state=21604000] [content=0x3dc4f670] sc=0x25b169c pst=:-moz-non-element<
      "01234"
    >
    Frame(br)(1)@0x25ac8ec {2400,666,0,0} [state=00004000] [content=0x3cff2390]
  >

Note the overflow area is wider than the div itself.  And that the textframe is 2340 twips wide, but the br frame starts at 2400 twips (so one pixel further).  That's basically the problem.  Any idea what's causing that?

All this is on Mac.  On Linux, we suffer from the equivalent of bug 364300, so testing is silly.

In any case, this is definitely a regression from 1.8.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Er, I guess the text is starting at position "60", so that explains the 2400 twips.  Hmm...

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 326123.  Fix coming up.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Although, that bug says:

  Notice that the outer dimentions of the controls themselves should *not* be
  adjusted to "compensate" for the 1px padding, if compatability with IE is
  required.

Does that mean that IE also doesn't size <textarea>s wide enough to avoid horizontal scrollbars?  Or does it size <input> and <textarea> differently?

Comment 5

[Uri Bernstein]

I can't reproduce this bug on WinXP or Mac with the given testcase and a latest (20070713) trunk nightly. I'll try Linux tomorrow.

As for what IE does: I tested both IE6 and IE7 on WinXP, with the default XP theme, and what happens there is that the "4" overflows to the second line (i.e., the line only has room for 4 characters, in spite of the cols="5"). IE apparently never displays a horizontal scrollbar on textareas - instead, it forces a line break in mid-word, if necessary.

Comment 6

[Boris Zbarsky [:bzbarsky]]

I think we should add the space for the padding in monospace mode only, then.

Comment 7

[[e-mail]]

(In reply to comment #5)
>IE apparently never displays a horizontal scrollbar on textareas
With the testcase as modified to include wrap="off" IE6 disables the horizontal scrollbar. Adding a sixth character enables the scrollbar of course.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Note that sizing in general is pretty screwed up with native theming.  For example, on Mac text controls are 2px wider than they would be without native theming....

Comment 9

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

Comment on attachment 272340 [details] [diff] [review]
Proposed fix

r+sr=dbaron

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 272340 [details] [diff] [review]
Proposed fix

Simple fix to adjust the width of our textareas and text inputs by 2px when using a fixed-width font to not end up with scrollbars when a number of chars equal to the cols or size is input.  Risk is low.

Comment 11

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

Comment on attachment 272340 [details] [diff] [review]
Proposed fix

a19=dbaron

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 13

[Samuel Sidler (old account; do not CC)]

v.fixed

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre