Textarea text scrolls under padding instead of over
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
Webcompat Priority | P1 |
People
(Reporter: erisds, Unassigned)
References
Details
(Whiteboard: [webcompat])
Attachments
(5 files)
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
Reporter | ||
Comment 1•10 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.
Comment 2•10 years ago
|
||
The scrollbars are on an anonymous block inside the textarea, not on the textarea itself...
Comment 3•10 years ago
|
||
Is this because textboxes have their overflow clip set to the padding box?
Comment 4•10 years ago
|
||
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.
Reporter | ||
Comment 5•10 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.
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•10 years ago
|
||
Fair enough, I guess we have to make an exception for <textarea> for compat reasons then.
Comment 9•6 years ago
|
||
It has been suggested that this is the cause for recent breakage on GitHub: https://github.com/webcompat/web-bugs/issues/18209
Comment 10•6 years ago
|
||
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•5 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 12•5 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•5 years ago
|
Comment 13•3 years ago
|
||
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
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•3 years ago
|
||
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?
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Bug 1456052 fixed this, but it broke google translate so had to be backed out. But that's the right fix, effectively.
Comment 18•3 years ago
|
||
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•3 years ago
|
||
Comment 20•3 years ago
|
||
Comment 21•3 years ago
|
||
Comment 22•3 years ago
|
||
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•3 years ago
|
||
That is bug 748518, so I'd say it's working as expected.
Comment 24•3 years ago
|
||
Perfect!! Thank you for linking that one.
Comment 25•3 years ago
|
||
I just randomly stumbled upon this again, but this time it was working!!
AWESOME
Thank you, Emilio!
Description
•