New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 22 users

Issue metadata

Status: Fixed
Closed: Jun 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Launch-OWP
Launch-Accessibility: ----
Launch-Exp-Leadership: ----
Launch-Leadership: ----
Launch-Legal: ----
Launch-M-Approved: 61-Dev , 61-Beta , 61-Stable
Launch-M-Target: 61-Dev , 61-Beta , 61-Stable
Launch-Privacy: ----
Launch-Security: ----
Launch-Test: ----
Launch-UI: ----

Blocked on:
issue 575

issue 157855

Sign in to add a comment

Issue 501568: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 0.31% of top 450k sites).

Reported by, Jun 17 2015

Issue description

Chrome Version       : 45.0.2432.0
OS Version: OS X 10.10.1
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

enabling #scroll-top-left-interop
make impossible to scrool on this webpage

What is the expected result?

What happens instead of that?

Please provide any additional information below. Attach a screenshot if

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2247.0 Safari/537.36

Comment 1 by, Jun 18 2015

Labels: Cr-Blink-Scroll

Comment 2 by, Jun 19 2015

Labels: M-45
Status: Untriaged
Tried the same on mac 10.10 chrome version 45.0.2435.5 observed that on enabling #scroll-top-left-interop in chrome://flags unable to scroll with mouse scroll wheel  keeping the point on the web page. 

If the mouse pointer is placed on vertical scroll bar and scrolled with mouse wheel the scrolling works fine

Scrolling works fine on all other pages

M44 Channel : Same behaviour
M43 cahnnel : #scroll-top-left-interop flag is not seen in chrome://flags

Comment 3 by, Aug 14 2015

Labels: Hotlist-Input-Dev
Status: Assigned
Rick, I think you are looking at some #scroll-top-left-interop issues right ?

Comment 4 by, Aug 15 2015

Yep, thanks - I'll take a look before shipping ( issue 157855 )

Comment 5 by, Aug 15 2015

Blocking: chromium:157855

Comment 6 by, Aug 17 2015

Labels: -OS-Mac OS-All
Status: Started
Appears to be due to some logic from "smooth-scroll.js" in the ssc_overflowingAncestor function.  Latest version of this code appears to live here:

Strange that that says it's a Chrome extension.  Perhaps someone has copied the relevant code from the extention and embedded it directly in a website (eg. from this GIST: or from

Still trying to understand what's broken about this logic or Chrome's behavior and why it works in other browsers.  Hopefully we just have a subtle bug.

Comment 7 by, Aug 17 2015

It appears to be the library logic that's wrong here, not Chrome's behavior.  If documentElement.scrollHeight > documentElement.clientHeight and it finds an ancestor of the mousehweel target 'e' where e.scrollHeight === documentElement.scrollHeight, then it attempts to use 'body' to scroll:

function ssc_overflowingAncestor(e) {
    var t = [];
    var n = ssc_root.scrollHeight;
    do {
        var r = ssc_cache[ssc_uniqueID(e)];
        if (r) {
            return ssc_setCache(t, r)
        if (n === e.scrollHeight) {
            if (!ssc_frame || ssc_root.clientHeight + 10 < n) {
                return ssc_setCache(t, document.body)                 // <--- problem
        } else if (e.clientHeight + 10 < e.scrollHeight) {
            overflow = getComputedStyle(e, "").getPropertyValue("overflow");
            if (overflow === "scroll" || overflow === "auto") {
                return ssc_setCache(t, e)
    } while (e = e.parentNode)

It should be using document.scrollingElement here instead of document.body.  So then why does it work on other browsers?  Because it only installs itself on Chrome or Safari (firefox doesn't support 'mousewheel' events, only the standard 'wheel' events):

    function t() {
        var e = navigator.appName, t = navigator.userAgent, n;
        var r = t.match(/(opera|chrome|safari|firefox|msie)\/?\s*(\.?\d+(\.\d+)*)/i);
        if (r && (n = t.match(/version\/([\.\d]+)/i)) != null )
            r[2] = n[1];
        r = r ? [r[1], r[2]] : [e, navigator.appVersion, "-?"];
        return r[0]
    var n = t().toLowerCase();
    if (!Modernizr.touch && (n === "firefox" || n === "chrome" || n === "safari")) {
        ssc_addEvent("mousedown", ssc_mousedown);
        ssc_addEvent("mousewheel", ssc_wheel);
        ssc_addEvent("load", ssc_init)

Comment 8 by, Aug 17 2015

The current version of the SmoothScroll chrome extension does appear to work fine (due to a fallback to window.scrollTo), but I filed this bug for them with details anyway:

Searching httparchive bodies (top 300k sites from 2014) I've found 157 sites which appear to include this buggy code (and spot checking a few, scrolling is indeed broken):

Comment 9 by, Aug 17 2015

Summary: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 157 of top 300k sites). (was: enabling #scroll-top-left-interop make impossible to scrool on this webpage

Comment 10 by, Aug 17 2015

Looks like many of these come from wordpress themes like this one:  They are also often installed only when 'chrome' is in the user agent string.  Perhaps this is what we get for leaving the popular  issue 575  unfixed for so long!

Comment 11 by, Aug 20 2015

Blockedon: chromium:575
Labels: -M-45 M-48
My plan is to help push smooth scrolling along ( issue 575 ) and once that has shipped we'll publish something encouraging people to stop using smoothscroll.js (it can only hurt scroll performance).  Then (with proper care / evangelism) we'll plan to break the sites still depending on that library.

Comment 12 by Deleted ...@, Dec 14 2015

Another site using this library:

Comment 13 by, Jan 4 2016

Labels: Hotlist-SmoothScroll

Comment 14 by, Jan 21 2016

Damn, this has jumped up a lot in the latest HTTPArchive data (Nov 2015) - now 1186 of top 450k sites (0.26%).  This seems potentially too high to break IMHO.

Maybe we could remove support for deprecated 'mousewheel' events first?

Comment 15 by, Jan 21 2016

Blockedon: chromium:580126
Let's consider this blocked on issue 580126 for now until I have data showing how realistic that may be.

Comment 16 by, Jan 21 2016

Summary: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 0.26% of top 450k sites). (was: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 157 of top 300k sites).)

Comment 17 by, Jan 21 2016

Blockedon: -chromium:580126
Yeah, removing mousewheel is even crazier than breaking this, probably not gonna happen anytime soon.  Let's see if we can drive smoothscroll.js usage down at all via evangelism (good to do anyway for perf reasons).

Comment 18 by, Jan 21 2016

As we talked about I'm all for native scrolling, but I'm still not loving the current implementation. *

I'm not sure how all the other devs will respond.

People using ss.js for parallax websites or combined with other scrolling animations may find the current default Chrome "smooth" scrolling too jummmpppy (like I do) so they may still want to customize the animation curve.

Is there a planned timeframe for the "Scroll Customization in Blink" project?

*the animation time is too short, multiple ticks feel like a series of jumps instead of one continuous motion. Plus there is no acceleration.

Comment 19 by, Jan 21 2016

Scroll customization is a work in progress - it's still in the early experimental stages, so it will be a while before it reaches the standardization process, and the standardization process is likely to take some time.

Comment 20 by, Jan 22 2016

Yeah, if developers really want to customize the effect on their site (and trade some scroll performance for that) I think that's fine.  I didn't mean to imply there was no use-case at all for your code - sorry :-).  I just want to drive down usage that either:
 1) depends on the WebKit bug we're trying to fix, or
 2) whose benefit is no longer worth the performance cost

Given that most sites I've seen don't appear to try to customize the smooth scroll behavior in IE/Edge, I suspect those developers aren't looking for advanced customization / tweaking of the behavior.

Have you filed bugs for the improvements you'd like to see?  I think it's great that  your extension is available for users to customize the experience - it's a very subjective thing and Chrome's goal is to do the best we can for the average user (without adding settings) then let extensions handle the non-average cases.

Comment 21 by, Apr 13 2016

Labels: -M-48

Comment 22 by, May 20 2016

Curious if there's been any movement on this issue. It's listed as blocking 157855 and 423935, which is keeping us ( from recording scroll positions on pages that use `body { height:100%}`.

Comment 23 by, May 26 2016

Hi there, just curious about the status of this blocker (to  Issue 157855 ), any progress? I mean developers do can use a wrapper element in the <body> to do the scrollTop trick, it's still inconvinient though. Thank you!

Comment 24 by, Jul 1 2016

Owner: ----
Status: Available (was: Started)
scrollTopLeftInterop is proving very difficult to achieve due to web compat - mainly smoothscroll.js.  We're explicitly putting work on hold for another quarter or two.  The hope is that usage will decline now that Chrome has built-in smooth-scroll, then it'll make sense to do another push to try to get scrollTopLeftInterop shipped and working everywhere.

Comment 25 by, Jan 26 2017

rybers@ it has been a few quarters now. How is the usage of smooth-scroll.js tracking. We have shipped Chromes smooth scroll for a few releases now.

Comment 26 by, Feb 4 2017

I've searched the top 450k sites in HTTP Archive for "ssc_wheel' in JavaScript and HTML files (and spot-checked a few results to verify most are indeed pages where scrolling is broken with --enable-experimental-web-platform-features).  Here's the number of hits at a few points over the past year:

5/15/2016: 1229
9/15/2016: 1343
1/15/2017: 1399

So there's no sign of dropping.  In addition to the impact this has on scrollTopLeftInterop, this is a scroll performance problem that would be valuable to solve.  I see only two potentially practical options:

1) Remove the mousewheel event - issue 580126
2) Add a hack so that addEventListener('mousewheel', f) is a no-op when"ssc_wheel" (likely permanent until #1 - I doubt we'd succeed in getting the long tail of sites here to update).

I'll push some more on the first option.  Perhaps we can consider the 2nd as an interim step if it seems like it'll take us awhile to do the right thing and drop mousewheel.

Comment 27 by, Feb 4 2017

Summary: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 0.31% of top 450k sites). (was: buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 0.26% of top 450k sites).)

Comment 28 by, Feb 4 2017

Blockedon: 580126

Comment 29 by, Jun 1 2017

Labels: -Type-Bug Type-Launch-OWP

Comment 30 by, Jun 1 2017

Status: Assigned (was: Available)

Comment 32 by, Jun 1 2017

Cool :)

Based on comment #8 we have two versions of smoothscroll.js to contend with:

(a) the broken one, still in the wild
(b) the current version which is compatible with 

Will your proposal have any negative effects on (b)?  I assume it relies on preventDefault to avoid double-scrolling.

Comment 33 by, Jun 1 2017

For case b) the function names changed so it isn't an issue.

Comment 34 by, Jun 2 2017

Project Member

Comment 35 by, Jun 9 2017

Project Member
The following revision refers to this bug:

commit 509091516cbcf85c5b34f1e80713db40b59285cd
Author: Dave Tapuska <>
Date: Fri Jun 09 18:31:29 2017

Enable Smooth Scroll.js intervention.

Add a console message indicating the library is no longer necessary and
it is being treated as a passive listener.

Approved intent to ship:

BUG= 501568 

Change-Id: I07e48572d046d6e47d65fd38a12a7ba2f2a68d74
Commit-Queue: Dave Tapuska <>
Reviewed-by: Jeremy Roman <>
Cr-Commit-Position: refs/heads/master@{#478343}

Comment 36 by, Jun 21 2017

Labels: Launch-M-Approved-61-Dev Launch-M-Approved-61-Beta Launch-M-Approved-61-Stable Launch-M-Target-61-Dev Launch-M-Target-61-Beta Launch-M-Target-61-Stable
Status: Fixed (was: Assigned)

Comment 37 by, Aug 7 2017

Blockedon: -580126
At first I thought I could actually see a change in our scroll performance metrics (Event.Latency.ScrollBegin.Wheel.BrowserNotifiedToBeforeGpuSwap2, Renderer4.WheelScrollingThreadStatus=SCROLLING_ON_COMPOSITOR_BLOCKED_ON_MAIN) correlated with this change in canary (61.0.3126.0 released June 10).  But that appears to be some unrelated site/usage change (can see the movement entirely within version 61.0.3122.0).

I see the UseCounter being hit on 0.03% of PageVisits on the Windows Dev release it was enabled (61.0.3128.0).  And of course 0.03% of PageVisits is too small to substantially influence our metrics even at the 99th percentile.  I'm a little surprised that something used by 0.3% of the top 500k sites shows up as only 0.03% of PageVisits, but I guess that's just a reflection of the long tail of the web and that this library's usage is heavily skewed towards the bottom end of the top 500k sites.

Sign in to add a comment