Why “window.scrollTo()” is Harmful for Mobile Websites

window scroll to method

There was a time when I thought snapping a mobile web page to (0,1) was a good idea for mobile websites. Since mobile devices have small screens, and some mobile browsers have a decent chunk of screen real estate taken up by an address bar and toolbar, it seemed like a no-brainer to use JavaScript to help hide the address bar, giving the site a more app-like feel for the user. That thinking is now a thing of the past, and I believe it’s time for developers to stop trying to control web pages for their users.


The Common “Fix”

For anyone who isn’t aware of the “fix” for hiding the address bar, here’s the long and short of it: Add a listener to your webpage for when the page has loaded, then call window.scrollTo(0,1), which effectively hides (or at least used to hide) the address bar. The following code snippet is a common example, though there are a handful of other variations.

window.addEventListener("load", function() {
  setTimeout(function() {
  }, 0);

(If you’re curious, the setTimeout in the code above is (was) needed for the iPhone to properly hide the address bar.)

In theory, this seems like a good idea, since it hides (used to hide) the address bar of the mobile browser to provide a larger viewing area for the user.

I take serious issue with this “fix”. And here’s why.

The Problem with the “Fix”

1. Jarring auto-scroll to the top of the page.
I’ve visited far too many mobile websites that use this “fix”, and in almost every case, I get frustrated as a user. In a time when developers are aiming to have faster and more responsive websites, users are quickly becoming accustomed to interacting with a web page before it’s completely finished loading. Content starts to appear, and the user begins to scroll down the page and consume the information. But on websites that implement the “fix”, especially websites that have a large amount of content/images/videos to load, users will often find themselves snapped back up to the top of the page for no good reason once everything is finally loaded. This leaves users needing to re-scroll down to find where they were on the page. And this is a horrible user experience.

2. Mobile browsers are becoming smarter.
In addition to the jarring auto-scroll issue, more and more mobile browsers are actually taking care of hiding the address bar for us – some of them even hide the toolbar, too. For instance, with the most recent updates to iOS 7, Safari now auto-hides the address and toolbars when the user starts to scroll. Ditto for Google Chrome. And Dolphin. And those are just a couple of the popular browsers for iOS.

The Solution

Because of the unfortunate and jarring user experience stemming from implementing the “fix”, and since mobile browsers are becoming smarter and taking care of hiding the auxiliary browser components, it’s time for developers to stop trying to control web pages for their users.

That said, well-meaning developers may still want to attempt to snap the user to the (0,1) spot just in case their mobile browser isn’t nice enough to hide the auxiliary browser components for them (Safari for iOS 6, for instance). This is all well and good, but only if we fix the “fix”.

How do we fix it? Here’s a simple update to the code from above:

window.addEventListener("load", function() {
  setTimeout(function() {
    var scrollPos = window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop;
    if (scrollPos < 1) {
  }, 0);

As you’ll notice, this code grabs the scroll position of the page BEFORE calling window.scrollTo(0,1). Why get the scroll position of the page first? Because we can use that value to see if the user has started to scroll down the page. If the scroll position is less than 1, we can assume the user hasn’t started scrolling, and can thus snap the user to (0,1). Otherwise, there’s no need to snap to that position, because the user has already started engaging with the page and is past it.

Wrapping Up

As I’ve stated, I believe that it’s time for developers to stop trying to control web pages for their users. But in case there’s still a need to do so, at least you have a better solution that won’t create a bad user experience.

Until next time, happy coding!

There are no comments yet, add one below.

Leave a Comment