Closed Bug 1320200 Opened 3 years ago Closed 3 years ago
scroll-behavior: smooth doesn't work with textarea
Bug 1320200 - Propagate scroll-behavior on a text input to the anonymous scrollable <div> inside it.
58 bytes, text/x-review-board-request
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20161122004020 Steps to reproduce: 1. Create a textarea, with some text, enought to need to scroll it to see it all. 2. Set scroll-behavior to smooth in the textarea CSS. 3. Use element.scrollTop to change the scroll position I created a jsfiddle for easily demostrate this: https://jsfiddle.net/soulchainer/0xxq06j0/1/ Actual results: Textarea just jumps to position determined by element.scrollTop property. The scroll movement isn't animated at all. It just jumps. Expected results: Textarea scrolling to position determined by element.scrollTop should be smoothly animated, just like any other element scrolled this way.
I tested your testcase with Nightly on Win 7, scrolling down/up the 2nd textarea is smooth, like on FF50.
Component: General → Panning and Zooming
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
(In reply to Loic from comment #1) > I tested your testcase with Nightly on Win 7, scrolling down/up the 2nd > textarea is smooth, like on FF50. The 2nd textarea? I guess I understood you wrong (or you understood me wrong). The 2nd textarea isn't a textarea, but a div. The div scrolls smoothly (it's only there for comparison). That's exactly the problem: I think the textarea scrolling (1st block of text) should be smoothly animated like the div (2nd block), but it doesn't.
Yeah, you're right, I thought both were textarea, but only the 1st one is a textarea and it's not smooth when scrolling down/up.
The frame tree for a text area has the following structure: nsTextControlFrame HTMLScroll The scroll-behavior:smooth is recorded on the nsTextControlFrame, but it's the HTMLScroll that we check when we decide whether or not to do smooth scrolling.
By contrast, if overflow:hidden is specified on the textarea, it gets propagated to both the nsTextControlFrame and the HTMLScrollFrame. Moving over to the CSS component.
Component: Panning and Zooming → CSS Parsing and Computation
(In reply to Botond Ballo [:botond] from comment #5) > By contrast, if overflow:hidden is specified on the textarea, it gets > propagated to both the nsTextControlFrame and the HTMLScrollFrame. Here's how this is accomplished: - The HTMLScrollFrame is generated by an anonymous <div> created by the TextControlFrame . - Under appropriate conditions, the code that sets up the <div> adds "inherit-overflow" to its class name . - We have some internal CSS that styles the <div>, when it has the "inherit-overflow" class, as "overflow: inherit", so it inherits the "overflow: hidden" from the <textarea> . (Thanks to Timothy for tracking this down!)  https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/layout/forms/nsTextControlFrame.cpp#337  https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/dom/html/nsTextEditorState.cpp#1808  https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/layout/style/res/forms.css#188
Component: CSS Parsing and Computation → Layout: Form Controls
Comment on attachment 8814520 [details] Bug 1320200 - Propagate scroll-behavior on a text input to the anonymous scrollable <div> inside it. https://reviewboard.mozilla.org/r/95732/#review95758
Attachment #8814520 - Flags: review?(tnikkel) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/2a80ee5b4cb1 Propagate scroll-behavior on a text input to the anonymous scrollable <div> inside it. r=tnikkel
You need to log in before you can comment on or make changes to this bug.