title: A simple solution to prevent scrolling problems mobile safari (iOS)
body: <p>Consider the following scenario:</p>
  
  <p>You have 2 scrollable elements.</p>
  
  <ol>
  <li>A long flowing list of items attached to $(document).scroll()</li>
  <li>A separate container/overlay that listens to $(".class").scroll()</li>
  </ol>
  
  <p><a href="https://i.stack.imgur.com/EEc0K.png" rel="noreferrer"><img src="https://i.stack.imgur.com/EEc0K.png" alt="enter image description here"></a></p>
  
  <p>With the following CSS properties.</p>
  
  <pre><code>body {
  overflow-y: scroll;
  height: 100%;
  }
  
  .class {
  height: 100%; /* 50% 20% 200px whatever you may */
  position: fixed;
  overflow-y: scroll;
  -webkit-overflow-scrolling: touch;
  }
  </code></pre>
  
  <p>In other words, a very standard setup, that in <strong>2017 should work without any issues on any device.</strong> Wrong.</p>
  
  <p>Here are the problems that I've experienced with this simple setup through the years, <strong>and never found a good, reliable solution to:</strong></p>
  
  <ol>
  <li>The overlay starts flickering from mild to extreme when scrolled to <strong>top</strong> or <strong>bottom</strong> of overlay when 100% height, no matter HTML complexity across all iDevices.  (Because of z-index issue with over-scrolling, or hardware acceleration issue, I don't know).</li>
  <li>The scrolling completely stops for the overlay when at the top or bottom in order to wait for body-scroll to stop over-scrolling.</li>
  <li><p>When the scrolling has wrongfully stopped for the container (whilist over-scrolling kicks in), and the user keeps scrolling, the body will scroll instead, resulting in very inconsistent user experience as the user will now end up somewhere else in the body-scroll than they were before opening the overlay. It's also annoying to have to stop scrolling in order to wait for over-scrolling to stop.</p></li>
  <li><p>if container is 100% height, and without scroll – If user starts
  scrolling, the body will scroll and scrollbar will be visible, but
  the page seemingly isn't scrolling, resulting in inconsistent user
  experience.</p></li>
  </ol>
  
  <p>Some of the solutions I've tried without any success.</p>
  
  <ol>
  <li>iScroll. iScroll stops the over-scrolling issue by preventing any touch events on document. But delivers inconsistent and bad scrolling experience imho. Besides it shouldn't even be needed anymore. </li>
  <li>Every other scrolling plugin imaginable.</li>
  <li>Event delegation – Trying to enable scroll for only the element that is being interacted with. Works on desktop. Not mobile safari.</li>
  <li>Every jQuery scrolling aid imaginable. Mild success but very inconsistent.</li>
  </ol>
  
  <p>It seems that whatever fix has been presented in the past, has somehow been depreciated for "various reason" (Don't mean to sound conspiratorial.)</p>
  
  <blockquote>
    <p>I read a few weeks back that Apple is working on an update for the
    scrolling for webkit to make it more homogenous across all types of
    content-types served on the iPhone. But until then, this simple setup remains very problematic on mobile Safari.</p>
  </blockquote>
  
  <p>I may have come up with a solution to this finally. But I'm very curious to hear how others are solving this issue in 2017...</p>
  
  <p><strong>Update 2018 for WebView Apps</strong>
  While Apple is making no efforts in solving this matter, the absolute best solution <strong>to completely eradicate any problems</strong> if you're building webview apps is to entirely disable browser-scroll (webview) completely directly in Swift.</p>
  
  <p>When your WebView has loaded simply use:</p>
  
  <pre><code>    override func viewDidLoad() {
          super.viewDidLoad()
          wkWebView1.scrollView.isScrollEnabled = false
          wkWebView1.scrollView.bounces = false
  }
  </code></pre>
  
  <p>And then in your CSS set the scrolling individually for each container that needs to be scrollable.</p>
  
  <p><strong>Note that $(document).scroll() will be completely disabled with this solution.</strong></p>
  
  <p>I hope it helps someone.</p>