Issue metadata
Sign in to add a comment
|
XHR Requests paused while Scrolling
Reported by
j...@discordapp.com,
Jun 29 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: (0) Join a Discord server with some chat history. A good candidate is https://discord.gg/overwatch (1) Using a mouse with inertial scrolling, or the touch pad, scroll up. (2) XHR requests are paused until scrolling stops. What is the expected behavior? XHR requests proceed as scrolling happens. What went wrong? XHR requests are paused - and will not complete until scrolling completes. Did this work before? Yes 56 Chrome version: 59.0.3071.115 Channel: stable OS Version: OS X 10.12.5 Flash Version: Here's a video of the issue: https://youtu.be/xyU-cqIGNF4 It demonstrates that the issue is not within the Discord application. In the console, I have a script that polls a site using `fetch` and measures how long the response takes to arrive. You can see that while scrolling, the response never arrives until I stop scrolling. Additionally, when scrolling up to load more messages, you can see that the XHR request remains in the "pending" state until scrolling stops. I've been able to reproduce this issue on multiple computers running OS X.
,
Jun 30 2017
,
Jun 30 2017
Reproduced the issue. Scheduler team, can you tell me if it's possible that the loading task runner is throttled during scroll?
,
Jul 4 2017
Yes, we can block loading tasks during scrolling if we the main thread is running the scroll animation. Does Discord implement its own scrolling or does it use native browser scrolling? (From the video it looks like the latter) To help debug, could you record a performance trace following these instructions and attach it to this bug: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug Be sure to check the "renderer.scheduler" category in the right hand side list.
,
Jul 7 2017
Attached is the trace file - with all the things checked.
,
Jul 28 2017
Any updates on this bug?
,
Aug 3 2017
skyostil: can you point me at the code that handles this? I'd like to understand what logic we're using better.
,
Oct 5 2017
Experiencing similar issues. Additionally, the xhr request remains pending for about 2s after scroll event. Found this previous bug/ bug comment that describes my situation exactly: https://bugs.chromium.org/p/chromium/issues/detail?id=649590#c12 Using keyboard or dragging the scrollbar doesn't introduce that 2s delay. Only mouse wheel (didn't try touch).
,
Oct 27 2017
This issue effects Canary 64 and stable 62 on WIndows 10 also. When scrolling quickly with the mousewheel, all XHR requests are blocked from returning until you stop scrolling. The easiest way to reproduce this on any machine is to go to your 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. Scrolling using a touchscreen or by dragging the scrollbar is not effected at al, and the XHR requests return normally.
,
Oct 31 2017
,
Oct 31 2017
crbug.com/780102 is master bug for tracking work around tuning task blocking during scrolling and other user gestures.
,
Nov 1
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 2
Removing Blink>Network>FetchAPI as there is nothing we can do here.
,
Nov 2
I'm slowly making progress here :) |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by e...@chromium.org
, Jun 29 2017