When entering long sections of text into a textbox in a browser (such as when using gmail or a site like this) we can scroll within that textbox, which is as it should be.

However, the behaviour of that textbox scrolling changes without direct user input when we get to the extremes of the textbox. It changes from scrolling within the textbox to scrolling the page. The result is that you can't quickly scroll to the top or bottom of a textbox in a browser in the same way that you can scroll to the top or bottom of a screen in a browser.

You can see this in a recording of a textbox scroll overflow that I made.

I find this to be poor UX wise, but it seems to be applied universally in browsers. What is the reasoning behind it, and is there any research supporting this behaviour?

  • 2
    Damn, YOU'RE the one asking? I thought to myself "Good question, I wonder what JohnGB thinks". – mowwwalker Mar 18 '13 at 20:25
  • 1
    @Walkerneo I have an opinion on it, but it's also useful to ask some questions and not just answer them all the time :) – JohnGB Mar 18 '13 at 21:30
  • I find it's the preservation of momentum across the transition the most confusing part of this. I can understand the desire for uniformity of input method to scroll through various content structures, but having a "self-scrolling" text-box hit the bottom and cause the page to scroll the text-box out of view is most unexpected. I find with Mac trackpad gestures more (than mouse wheel) you can spin up a text-box to very high speeds with a flick. My fingers aren't even touching the pad when the transition happens. – scipilot Jun 14 '16 at 13:25

I was unable to find research that supports this, so if anyone knows of anything proving or disproving what I am about to assert, please feel free to add a comment.

My assumption on this behavior is that the rules of scrolling are hierarchical and the browser has a chain of "responders" that will receive the scroll message from the browser. When the browser scrolls, the event is messaged to the scrolling chain which is defined by the user's focus and then stepping outward through the DOM.

In this example, the first responder is the textbox. When it receives the scroll message, it will check its scroll position and increment/decrement accordingly. Unless it is at it's max/min, in which case it will pass the scroll message to it's parent scrollable object, until eventually that scroll message is received by the browser window's scroll bar.

Despite its faults (as evidenced in the question), allowing scrolling to scroll "out of" the initial container is better than the alternative, which is to only scroll within the focused element.

WHY this is actually good UX is that the average user is not going to understand the implicit hierarchy of scrolling, and could become "trapped" in a textbox.

The only way out would be to un-focus the textbox by clicking or tabbing off the element, which is not easily discoverable and I'm not sure what affordance one could give to indicate that unfocusing the element will allow full-page scrolling.

A hierarchy of scrolling, while problematic, does not constrict the user. The browser is taking a "you're the boss" approach in deferring to the user's scrolling which from a meta level is good UX.

Edited to add: However it might be nice to allow for CTRL+scroll or some other keyboard chord which a power user could use to limit scrolling to the focused element (the chord would restrict the scroll message to the focused element and prevent the message from being pushed up the tree if the element's scroll position is at max/min).

  • Love the CTRL+scroll idea. How just get Chrome to support it :) – JohnGB Mar 20 '13 at 22:15

The 'pro' reason I can think of for this is, when you have reached the end of the text box, navigation-wise, you want to move to the next entity on the page, which is below the text box. Hence, when you scroll to the bottom of the box, you continue scrolling on in the page.

The annoyance arises when, instead of going further, you want to go back.

A couple suggestions for solving the annoyance: - Add a delay in scrolling down after you have reached the end of the box. - Along the same line as above, add a snapping gravity effect to the scroll. You freely scroll to the end of the box, then you need to scroll harder(more) to get it to scroll the page.

edit 1

Scenario 1: I am scrolling down a long text box to find a particular sentence I had read a while ago. Because I was scrolling quite fast, I end up missing the end of the text box and go on scrolling the page. Leading me to scroll back up to the text box and then scroll back in the box to resume my search.

If there was a delay when I reached the end of the box, if would stop me from scrolling on and I can resume my search by scrolling up again.

The delay acts as a safety net here. Rather than needing an "undo" experience, the delay prevents the user from making the 'mistake' in the first place.

I will have to find an example of using delay in usability domain. But, there are plenty of examples for using delay to induce trust factor since people do not trust systems that work too fast for them to comprehend. example: http://danariely.com/2010/12/15/locksmiths/

  • Welcome to UX.SE! I'm interested by your answer, particularly the last bit. Can you explain why adding the delay or the effect will improve the UX? Bonus points if you cite some references! – Charles Wesley Mar 18 '13 at 15:51
  • Pressed return by mistake Answering in a bit – rk. Mar 18 '13 at 16:01
  • It might be easier to edit your response into your answer as it gives a bit more room! – Charles Wesley Mar 18 '13 at 16:03
  • +1 for mentioning user trust and how the experience can engender or diminish trust in the system – Charles Wesley Mar 18 '13 at 16:29

Yes and no. A textbox shouldn't scroll it should expand according to its current content. When the textbox + the other content expands further than the height of the browser window - a scrollbar should be visible to the right.


download bmml source – Wireframes created with Balsamiq Mockups


If there are technical limitations, such as a fixed Rich Text editing field where scrolling inside the textbox is the only option, the behaviour should be context sensitive. If you are scrolling inside a textbox - reaching the end, you should not continue to scroll in another context (the entire page).

It brings cognitive load to the user where she needs to scroll carfully not to loose the entire control scrolling the page down instead of the textbox. The problem with this behaviour is that the user still has focus (technical) within the control but the control is invisible to the user. If the user would continue typing, changes would be made inside the textbox, hidden to the user.

The other usually used controls, such as CTRL + End to move to the end of th e textbox, and CTRL + Home to move to the start of the textbox still works as expected.

Context enabled controls have been around since at least the introduction of the ribbon in Microsoft Office 2007, so the idea isn't new. But the implementation need to change to make users in control (visually and in context) of what they are doing.

To answer your question, on the reasoning behind it is hard. But there is probably no real design reasoning behind it. It just happened. If it where a design choice, the CTRL + End and CTRL + Home would have behaved the same, but they don't. This is probably the work of a series of accidental errors based on too narrow focused design (controls) and not the entire web page.

  • Given that many (if not most) textboxes don't expand (often for technical reasons), what should be scroll behaviour be at the extremities of the textbox? – JohnGB Mar 18 '13 at 15:03
  • @JohnGB I've updated my answer accordingly. – Benny Skogberg Mar 18 '13 at 17:00

Depending on how you're using the text box would justify the setup on a page. For example, if you were creating a form and a user is filling out a textbox field, I would contain the field within a smaller column and row size. That way the user isn't endlessly scrolling withing the page.

Example of set columns and rows within textbox Example of set columns and rows within textbox

The smaller size has drawbacks as the user can't view "all" the information they have typed in a larger space; however, the page scroll is more contained. Expanding the text box can also be a solution.

As for materials on the subject, there isn't much out there research-wise supporting this behavior.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.