Chrome doesn't process XMLTHTTPRequest response while user is scrolling the page
Reported by
sta...@gmail.com,
Sep 23 2016
|
||||||||
Issue description
Chrome Version : 53.0.2785.116
OS Version: OS X 10.11.6
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5: OK
Firefox 4.x: OK
IE 7/8/9:
PROBLEM:
Chrome doesn't process XMLTHTTPRequest response if the user is keeps scrolling the page. Also in certain cases, it will not process the response until 2 seconds *after* the user stopped scrolling. So for example, if the user scrolls to the end of the page and clicks on a lick that does and AJAX call, there will be a 2second delay until the ajax call completes, although in the network logs we can see the request took less than a few milliseconds.
Please have a look at the following youtube video, demonstrating the problem:
https://www.youtube.com/watch?v=Mix6xXRJddI
What steps will reproduce the problem?
* You will need to run webpack-dev server using the attache project. It is in elm, but I originally saw the bad behavior with pure javascript.
0. Install elm and node and webpack-dev-server
1. untar/gunzip and run elm-make and npm install
2. run "npm run dev"
3. visit http://127.0.0.1:8080
4. start scrolling up and down using you mouse wheel or your touchpad
5. while scrolling click on the "Mad" header
6. keep scrolling
You will observe in the console, that the AJAX request doesn't get processes until you stop scrolling (see video above).
(It may need a couple of tries to get it to reproduce, but once you reproduce one, you will be able to do so consistently)
UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36
,
Sep 23 2016
Hey Stanis, Where did you get this error from? The repro that I attached, doesn't use MySQL. Thanks, Stavros
,
Sep 25 2016
A couple of screenshots for the same request. In the first we see the "Network" tab in the developer tools, where the request "/api/dashboard" takes 9ms. In the second we see the "Timeline" tab in the developer tools, where the same request we show in "Network" tab(not a different one to the same API, the exact same request) says it is taking 10+ seconds!
,
Sep 26 2016
I'm seeing the exact same behavior on Mac / 53.0.2785.116. Out of curiosity, and as a test, I even made an iframe and used postMessage to proxy the XHR's through just to see if I could trick it with message events. It has the same behavior even when using window `message` events. Perhaps it's obvious, but it's not isolated to XHR's because it's also waiting ~2+ seconds to process `message` events on `window`. In my case, it's an infinite scroll scenario where I need to load data while the user is scrolling, so it's unacceptable to wait to handle XHR responses.
,
Sep 27 2016
,
Sep 28 2016
Thank you for reporting. Could you post a tracing log (See https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs)?
,
Sep 28 2016
Please find attached the tracing logs and a screenshot of the debug logs with the timestamps. Please don't hesitate to ask for more info or logs or captures. Thanks! Stavros
,
Sep 28 2016
I believe this is the event in the traces: ID 0xaf788db4a6a1b4ee Title WebURLLoaderImpl::Context::Start Category loading Start 4,801.952 ms Wall Duration 6,628.469 ms From Slice WebURLLoaderImpl::Context::Start at 4,801.929 ms To Slice WebURLLoaderImpl::Context::OnReceivedResponse at 11,430.421 ms
,
Sep 30 2016
It seems that this issue is affecting the loading of images which are applied as background-image. These images are gaining a low priority level. You can see this occuring at http://g1.globo.com (it's easier to realize when using a mobile viewport size) Each feed's item use this technic to display images. I've noticed that xhr requests are being affect either, exactly as the first post of this thread describes.
,
Oct 4 2016
I've noticed that it's happening at chrome for android too
,
Oct 17 2016
This also happens on Windows. We have an application where the 2s delay occurs only when scrolling with scroll wheel or with two finger scrolling. It does not occur when scrolling using the scrollbar or the up/down arrow keys.
,
Oct 19 2016
Adding Blink>Scheduling. Do you think it's a scheduling issue? > scheduling people
,
Oct 26 2016
It seems that was fixed in Chrome 54
,
Dec 2 2016
It seems someone fixed this issue. jan.boes...@gmail.com, feel free to file a new bug if your issue persists. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by stanisl....@gmail.com
, Sep 23 2016