Project: chromium Issues People Development process History Sign in
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
Status: Fixed
Owner:
OOO Sept 14-Sept 25
Closed: Jun 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Launch-OWP
Launch-Accessibility: ----
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-Status: ----
Launch-Test: ----
Launch-UI: ----
Product-Review: ----

Blocked on:
issue 575

Blocking:
issue 157855



Sign in to add a comment
buggy smoothscroll.js prevents scrolling with #scroll-top-left-interop enabled (on 0.31% of top 450k sites).
Reported by ale160...@gmail.com, Jun 17 2015 Back to list
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
https://www.topresellerstore.it/

What is the expected result?


What happens instead of that?


Please provide any additional information below. Attach a screenshot if
possible.

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 b...@chromium.org, Jun 18 2015
Labels: Cr-Blink-Scroll
Cc: tkonch...@chromium.org
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
Labels: Hotlist-Input-Dev
Owner: rbyers@chromium.org
Status: Assigned
Rick, I think you are looking at some #scroll-top-left-interop issues right ?
Comment 4 by rbyers@chromium.org, Aug 15 2015
Yep, thanks - I'll take a look before shipping ( issue 157855 )
Comment 5 by rbyers@chromium.org, Aug 15 2015
Blocking: chromium:157855
Comment 6 by rbyers@chromium.org, 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: https://github.com/galambalazs/smoothscroll/blob/master/src/sscr.js#L547

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: https://gist.github.com/salipro4ever/35ba6d9e61cade99a0c2 or from https://code.google.com/p/rada-solutions/source/browse/trunk/Proyectos/DIGIP/Temperatura/Proyecto/Digip+Framework/App_Theme_Responsive/js/scroll/smoothscroll.js?r=178)

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 rbyers@chromium.org, 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)
        }
        t.push(e);
        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 rbyers@chromium.org, 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: https://github.com/galambalazs/smoothscroll/issues/111

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):
https://docs.google.com/spreadsheets/d/1P4kJfl-f5jeiKzYJyKVeo79NJEDL565Agcgl5hRh5ic/edit?usp=sharing


Comment 9 by rbyers@chromium.org, Aug 17 2015
Cc: mike.she...@gmail.com esprehn@chromium.org tdres...@chromium.org toniki...@chromium.org sim...@opera.com
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 https://www.topresellerstore.it/)
Looks like many of these come from wordpress themes like this one: http://themeforest.net/item/jarvis-onepage-parallax-wordpress-theme/5370691.  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!

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: http://ppt.on.ca/
Labels: Hotlist-SmoothScroll
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?
Blockedon: chromium:580126
Let's consider this blocked on issue 580126 for now until I have data showing how realistic that may be.
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).)
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).  https://plus.google.com/+RickByers/posts/RdYaYF5DTF4
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.
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.
Cc: skobes@chromium.org
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.
Labels: -M-48
Comment 22 by joel@fullstory.com, 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 (fullstory.com) from recording scroll positions on pages that use `body { height:100%}`.
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!
Cc: rbyers@chromium.org
Owner: ----
Status: Available
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.
Cc: dtapu...@chromium.org
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.
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 f.name=="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.


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).)
Blockedon: 580126
Labels: -Type-Bug Type-Launch-OWP
Owner: dtapu...@chromium.org
Status: Assigned
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 
ScrollTopLeftInterop

Will your proposal have any negative effects on (b)?  I assume it relies on preventDefault to avoid double-scrolling.
For case b) the function names changed so it isn't an issue.
Project Member Comment 34 by bugdroid1@chromium.org, Jun 2
Project Member Comment 35 by bugdroid1@chromium.org, Jun 9
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/509091516cbcf85c5b34f1e80713db40b59285cd

commit 509091516cbcf85c5b34f1e80713db40b59285cd
Author: Dave Tapuska <dtapuska@chromium.org>
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: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ

BUG= 501568 

Change-Id: I07e48572d046d6e47d65fd38a12a7ba2f2a68d74
Reviewed-on: https://chromium-review.googlesource.com/529424
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#478343}
[modify] https://crrev.com/509091516cbcf85c5b34f1e80713db40b59285cd/third_party/WebKit/Source/core/events/EventTarget.cpp
[modify] https://crrev.com/509091516cbcf85c5b34f1e80713db40b59285cd/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

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
Blockedon: -580126
Cc: nzolghadr@chromium.org
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