setTimeout and XHR requests are ignored while user is scrolling.
Reported by
t...@bluecrow.biz,
Nov 1 2016
|
|||||
Issue description
Chrome Version : Version 52.0.2743.116
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: OK
Firefox: OK
IE: OK
What steps will reproduce the problem?
Ff the user is scrolling all XHRs and setTimeouts will be delayed until scrolling stops. The behavior is described in this blog post: https://blog.chromium.org/2015/04/scheduling-tasks-intelligently-for_30.html Although this feature helps mobile scrolling, it is disastrous for infinite scroll.
Put this in a snippet, run it then start scrolling immediately. The setTimeout will not be called until after the scroll finishes.
var p = new Promise(function (resolve) {
setTimeout(function () {
console.log('resolving');
resolve();
}, 1000)
});
p.then(function () {
console.log('DONE!!');
})
What is the expected result?
setTimeout and XHR requests should be called while the user is scrolling.
What happens instead?
setTimeout and XHR requests are not called while the user is scrolling.
Please provide any additional information below. Attach a screenshot if
possible.
,
Nov 2 2016
Unable to reproduce the issue on Windows 10 using chrome stable M54 #54.0.2840.87 . Attached screencast for reference. Could you please try updating your chrome and try again. If you still face the issue please write us with your observations. Thanks !
,
Nov 7 2016
Do you have touch handlers on your page? This throttling should not be happening on most pages where we scroll using the compositor. Could you attach an HTML file that can be used to reproduce this -- or is the snippet above enough?
,
Nov 19 2016
I can no longer reproduce this. You can close.
,
Nov 27 2016
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 22 2016
Thanks for the update, closing the issue as per C#4.
,
Oct 26 2017
This issue still effects Canary 64 and stable 62. When scrolling quickly with the mousewheel, all XHR requests are blocked from returning until you stop scrolling. Perhaps the issue has only been fixed with regards to promises and timeouts. The easiest way to reproduce this on any machine is to goto you Facebook newsfeed and begin scrolling down by hammering the mousewheel downwards. Facebook's XHR requests will fire, but they won't return anything in order to add news items to the feed until you completely halt the mousewheel. Scrolling using a touchscreen is not effected at all, the XHR requests return normally.
,
Jan 24 2018
I'm on 63.0.3239.84 (Official Build) (64-bit) and see this with timeouts while scrolling using a Macbook trackpad.
,
Jan 25 2018
hello, i'm also on 64.0.3282.119 (Official Build) (64-bit) and see this with some XHR requests i do to load an VPAID ad on scroll event. Trying the same using the scrollbars or keyboard arrows makes the call faster you can check the demo page bellow: http://projectagora.com/devenv/vpaid_demo/test/giannoudak/ please compare the AdLoaded text value on the right side when using wheel vs the scrollbar. You will see that the ad loaded time is about 1.5~2 seconds smaller in case of scrollbar i have attached you a screenshot from wheel scroll vs scrollbar timings. as you can see in the wheel_scroll the diff between ad requsest and ad loaded is higher is there any workaround on this?
,
Feb 19 2018
Hi all, I'm also seeing this issue. I've attached a page that triggers the issue in Chrome 64.0.3282.167 (stable) and 66.0.3350.0 (canary) on MacOS 10.13.3. The issue is that the image loading is delayed until there's a break in the user scrolling. From what I can tell: - Only occurs if there is a touch handler somewhere on the page (doesn't seem to matter if it's passive or not) - Doesn't affect network requests in Web Workers (which is a potential workaround for this in some situations, but not for ads) - Happens more reliably if 6x CPU slowdown emulation is enabled.
,
Feb 26 2018
Also meeting this on Chrome 64, Mac OSX, scroll interaction blocks `Promise` makes it takes super long time to resolve/reject, below is my system info Would chromium team check above evidence and try to reopen this issues?
,
May 14 2018
Hi, This issue still exists in Ubuntu 16.04 LTS, Chrome Version 66.0.3359.170 (Official Build) (64-bit) and also in Mac OS Chrome. I am using ReactJs plus with React Virtualized Window Scroller Component, So whenever the user starts scrolling all Promise requests shows in pending state in chrome network inspector. When user stops scrolling then all requests sent to a server. Please, this issue is still available and it's preventing me to launch my project. Thank you.
,
Aug 9
I have just updated to Version 68.0.3440.106 (Official Build) (64-bit) and the issue seems to have improved significantly. I am no longer seeing a >1.5s delay in setTimeouts being executed following a touch screen scroll. I didn't see anything obvious in the release notes relating to this issue, but has something been changed in Chrome 68 to fix it?
,
Aug 20
There were no changes in Chrome 68. We're tracking work to remove the blocking logic completely in issue 874836.
,
Sep 5
android webview chrome version 68.0.3440.91 setTimeouts and image.onload still have delay about 2s after scrolling end.
,
Sep 10
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dtapu...@chromium.org
, Nov 1 2016