Description: When entering a large amount of text into the input prompt, the auto-scroll functionality that should bring the most recent text into view is not working. This results in the inability to view or edit text at the bottom of the prompt without manually scrolling. The expected behavior is for the prompt to auto-scroll to the bottom as the input reaches its maximum visible length.
Steps to Reproduce:
Log in to the platform.
Begin creating a new topic or inputting text into a field that supports extended text entries.
Continue inputting text until the content exceeds the visible area of the input prompt.
Expected Result: The input prompt should auto-scroll to the bottom, making the most recently entered text visible.
Actual Result: The input prompt does not auto-scroll, and the bottom of the text is not visible without manual scrolling.
Frequency: Consistently reproducible with long text entries.
Input and auto scrolling is broken since the last update. Also when you type enough text into the input, the input takes 100% height basically and you cannot scroll up anymore to see previous messages. Page up, page down, don’t work properly, home, end also not. This has to be fixed asap, it’s really annoying.
Every linefeed scrolls the top of the input box into view, hiding the bottom where entry happens.
Scenario 1:
Type => shift-enter => top of the textbox scrolls into view => reach for the mouse.
Scenario 2:
Go into the middle to edit or insert text while looking at what’s above and below => press any key => textbox is scrolled so that the active line is at the very bottom => you don’t see what’s below anymore => reach for the mouse => press any key => textbox scrolls again.
Super annoying. Stop playing with it. Textboxes have worked just fine for a really long time.
How it should work:
1, Cursor is above the visible area => key is pressed => scroll so that the cursor is on the top visible row
2. Cursor is below the visible area => key is pressed => scroll so that the cursor is on the bottom visible row.
3. Cursor is visible => key is pressed => cursor goes out of visible area => goto 2.
I imagine browsers handle this correctly on their own. No need for trickery.