1099204 - Textarea text scrolls under padding instead of over

Status: RESOLVED DUPLICATE of bug 1456052

(Core :: Layout: Form Controls, defect)

Description

[Hannah Wolfe]

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

[Hannah Wolfe]

Originally reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=157846#c156 raising as a new bug at the suggestion of @:Ms2ger.

Comment 2

[Boris Zbarsky [:bzbarsky]]

The scrollbars are on an anonymous block inside the textarea, not on the textarea itself...

Comment 3

[Timothy Nikkel (:tnikkel)]

Is this because textboxes have their overflow clip set to the padding box?

Comment 4

[Mats Palmgren (inactive)]

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.

Comment 5

[Hannah Wolfe]

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.

Comment 6

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

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.

Comment 7

[Mats Palmgren (inactive)]

Fair enough, I guess we have to make an exception for <textarea> for compat reasons then.

Comment 8

[m.kurz]

Any progress on this issue?

Comment 9

[Brian Birtles (:birtles)]

It has been suggested that this is the cause for recent breakage on GitHub: https://github.com/webcompat/web-bugs/issues/18209

Comment 10

[Karl Dubost💡 :karlcow]

And this is "breaking" the GitHub comment section. See https://webcompat.com/issues/18209


It has a very similar behavior than Bug 752790 where Mats solved it with (if I got it right)
  overflow-clip-box: padding-box content-box

Comment 11

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 12

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 13

[Ole Strøm]

Attachment: Screenshot of the comment textarea on Github, showing that the content is still being cropped due to padding.

Comment 14

[Ole Strøm]

Attachment: Screenshot of the comment textarea on Github with the inspector open, showing that the content is still being cropped due to the highlighted padding.

Comment 15

[Ole Strøm]

Regarding the webcompat stuff, it still is broken, but way less noticeable when it's 8px rather than 40px.

Made a comment about it on https://github.com/webcompat/web-bugs/issues/18209#issuecomment-769982657

Attached the same screenshots above.

Comment 16

[Ole Strøm]

Originally I was just having a good time creating a component that used a textarea.

All was good, until I added some padding to it.

Then it became harder to use and way less accessible.

I spent some time fiddling with it, but came short on all my attempts. My general searches came up empty.
Then I opened it Chrome, and it worked as expected.

I narrowed my search to "firefox textarea padding bug" and found the old issue at https://bugzilla.mozilla.org/show_bug.cgi?id=157846
It seemed unrelated first, until I saw the comment https://bugzilla.mozilla.org/show_bug.cgi?id=157846#c155

And it was exactly what I was experiencing!

Unfortunately, it seemed like Hannah didn't file a new bug, but after some more desperate searches, I found this issue!
Though not closed, it was at least reopened, so I had hope. Even more so when there was an issue with Github regarding it.

Sadly, it seems this bug got ignored after Github solved it for them them by replacing a very noticeable 40px padding with a barely noticeable 8px instead.

But the issue still remain.

And it is driving me nuts.

This is my last resort to solve it before I have to let it go due to time constraints, and let Firefox users suffer, rather than all the others.

Does anyone know of a workaround, some weird -moz-textarea-padding-box-sizing: border-box magic or anything, until I might be able to dig into this and try and solve it myself?

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Bug 1456052 fixed this, but it broke google translate so had to be backed out. But that's the right fix, effectively.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Let's dupe forward, I'll try to reland bug 1456052.

Ole, can you confirm that if you go to about:config, change layout.css.overflow-clip-box.enabled to true, and set overflow-clip-box: padding-box content-box on the textarea with your example, it behaves as you expect?

Thanks.

Comment 19

[Ole Strøm]

Attachment: Screenshot of the comment textarea on Github, showing correct padding on the top, with "overflow-clip-box: padding-box content-box"

Comment 20

[Ole Strøm]

Attachment: Screenshot of the comment textarea on Github, showing correct cropping with "overflow-clip-box: padding-box content-box"

Comment 21

[Ole Strøm]

Attachment: Screenshot of the comment textarea on Github, showing erroneous padding on the bottom, with "overflow-clip-box: padding-box content-box"

Comment 22

[Ole Strøm]

Thank you, Emilio!!

So glad to see this being progressed.

I toggled layout.css.overflow-clip-box.enabled to true, and slapped on overflow-clip-box: padding-box content-box the Github comment box.

It's so close to working as you'd expect, as I'd say it's good to go!! Check out the screenshots above.

There's one issue with the bottom of it, check https://bug1099204.bmoattachments.org/attachment.cgi?id=9200379

I manually changed the padding from 8px to 20px to showcase it better.

The padding bottom is ignored or something, so the last line has no padding - you cannot scroll further, as you'd expect. Like the top padding.

Comment 23

[Emilio Cobos Álvarez (:emilio)]

That is bug 748518, so I'd say it's working as expected.

Comment 24

[Ole Strøm]

Perfect!! Thank you for linking that one.

Comment 25

[Ole Strøm]

I just randomly stumbled upon this again, but this time it was working!!

AWESOME

Thank you, Emilio!