Closed Bug 1320200 Opened 3 years ago Closed 3 years ago

scroll-behavior: smooth doesn't work with textarea

Categories

(Core :: Layout: Form Controls, defect)

52 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox53 --- fixed

People

(Reporter: juanriqgon, Assigned: botond)

References

()

Details

Attachments

(1 file)

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 [1].

  - Under appropriate conditions, the code that sets up the <div>
    adds "inherit-overflow" to its class name [2].

  - 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> [3].

(Thanks to Timothy for tracking this down!)

[1] https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/layout/forms/nsTextControlFrame.cpp#337
[2] https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/dom/html/nsTextEditorState.cpp#1808
[3] https://dxr.mozilla.org/mozilla-central/rev/bad312aefb42982f492ad2cf36f4c6c3d698f4f7/layout/style/res/forms.css#188
Component: CSS Parsing and Computation → Layout: Form Controls
Assignee: nobody → botond
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 bballo@mozilla.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
https://hg.mozilla.org/mozilla-central/rev/2a80ee5b4cb1
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
See Also: → 1425485
You need to log in before you can comment on or make changes to this bug.