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
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...
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.
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.
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.
Fair enough, I guess we have to make an exception for <textarea> for compat reasons then.
Any progress on this issue?