Textarea text scrolls under padding instead of over




Layout: Form Controls
3 years ago
6 months ago


(Reporter: Hannah Wolfe, Unassigned)


33 Branch

Firefox Tracking Flags

(Not tracked)




3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36

Steps to reproduce:

1. Add padding-bottom and/or padding-top to a textarea using CSS (using 20px or more makes this problem more obvious).
2. Fill the textarea with text until it is forced to scroll vertically.
3. Scroll the text inside the textarea using any method/input device - keep an eye on the boundary between the text and padding.

Please also see this jsFiddle demonstrating the problem which was kindly prepared by Paul Adam Davis: http://jsfiddle.net/af47whzf/1/

Actual results:

The text scrolls underneath the padding, disappearing from view

Expected results:

The text scrolls over the padding, not disappearing until it reaches the edge or border of the textarea.

This is the behaviour exhibited by chrome, safari and IE

Comment 1

3 years ago
Originally reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=157846#c156 raising as a new bug at the suggestion of @:Ms2ger.
The scrollbars are on an anonymous block inside the textarea, not on the textarea itself...
Whiteboard: DUPEME
Is this because textboxes have their overflow clip set to the padding box?
We clip at the content edge for <input> and <textarea> (bug 965237), so yes,
the rendering of the testcase is intentional.  It makes sense for replaced
elements to have the same behavior, and authors expect to see no overflow
into the padding when scrolled to the end.

I guess I should make a proposal on www-style@ to standardize our hidden
'overflow-clip-box' property, so that authors can pick the clip area
they want.  I'll try to do that soon.

Please note that the rendering of the testcase in other UAs violates
the CSS box model.  See recent discussion on www-style on the matter.
Last Resolved: 3 years ago
Resolution: --- → INVALID

Comment 5

3 years ago
Hi there, original reporter here. I'd really appreciate it if :mats or someone else would please take the time to fully explain why this bug is invalid. 

I've provided a clear testcase where Firefox behaves completely differently to every other major browser and therefore does something different to what an author expects. It's also not something that can be worked around as far as I can tell. By what process is it considered invalid?

The original bug report from which this is split off (bug 157846) also talks about inconsistent behaviour being different to incorrect behaviour, and in that case following what the other browsers do was decided to be correct. Why is that not true here? i.e. in what circumstances does Firefox follow standards vs following the standard implementation?

> rendering of the testcase in other UAs violates the CSS box model
I'd love to read a clear explanation of why, as well as some consideration of why other UAs feel that this is an acceptable violation and whether this should perhaps be standardised.

> See recent discussion on www-style on the matter.
Could you possibly link to the discussion? 

> I guess I should make a proposal on www-style@ to standardize our hidden
'overflow-clip-box' property
I've found [the documentation](https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-clip-box) for `overflow-clip-box` which seems to suggest that setting `overflow-clip-box: padding-box` ought to be the missing workaround. Is this correct?

Thank you for your time.
Flags: needinfo?(mats)
We shouldn't be marking form control bugs as invalid based on theories about the box model when our behavior is different from all other browsers.
Ever confirmed: true
Resolution: INVALID → ---
Fair enough, I guess we have to make an exception for <textarea> for compat reasons then.
Flags: needinfo?(mats)
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: DUPEME

Comment 8

11 months ago
Any progress on this issue?
You need to log in before you can comment on or make changes to this bug.