Closed Bug 1099204 Opened 10 years ago Closed 4 years ago

Textarea text scrolls under padding instead of over

Categories

(Core :: Layout: Form Controls, defect)

33 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1456052
Webcompat Priority P1
Tracking Status
firefox62 --- affected
firefox63 --- affected
firefox87 --- affected

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
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.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
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
Any progress on this issue?
It has been suggested that this is the cause for recent breakage on GitHub: https://github.com/webcompat/web-bugs/issues/18209
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
Flags: webcompat?
Whiteboard: [webcompat]

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

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → revisit
Flags: webcompat?
See Also: → 157846

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.

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?

Webcompat Priority: revisit → P1

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

Depends on: 1456052

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.

Status: REOPENED → RESOLVED
Closed: 10 years ago4 years ago
Resolution: --- → DUPLICATE

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.

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

Perfect!! Thank you for linking that one.

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

AWESOME

Thank you, Emilio!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: