Browser freezes(waiting for ajax call) after few async ajax calls
Reported by
rajdgrea...@gmail.com,
Oct 4 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Go to https://erosnow.com/movies/mostpopular using latest chrome (Version 61.0.3163.100)..The issue is not happening with older versions of chrome. Not happening with other browsers also (firefox, safari etc) 2. Keep scrolling down. After around 8 pages, the browser will hang for some time (20 seconds - forever). When checked in network tab of dev tools, its waiting for ajax call response (but its a async call, so front end should not hang waiting for ajax call to complete) 3. After sometime if page freeze issue is resolved automatically and content is rendered, scrolling down again cause the issue to occur again (this time for another ajax call) What is the expected behavior? Browser should not freeze after any number of ajax calls What went wrong? It's still working fine for all browsers (firefox, safari, older versions of chrome). Seems like a bug in latest version of chrome only. Did this work before? Yes 60.0 Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.10.5 Flash Version:
,
Oct 5 2017
Able to reproduce the issue on reported version 61.0.3163.100 stable and on latest canary 63.0.3232.0 on Ubuntu 14.04, windows-10 and Mac 10.12.6. Bisect Information: =============== Good build: 60.0.3112.0 Bad Build: 61.0.3113.0 You are probably looking for a change made after 475029 (known good), but no later than 475030 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/2fde6d35bd484cc0cb9a4b7964f0a5e2cf000a6a..f26257b9ee4b7e722cc05468ceecbcf3f920be22 Suspecting https://chromium.googlesource.com/chromium/src/+/f26257b9ee4b7e722cc05468ceecbcf3f920be22 from above CL @samans:Please confirm the bug and help in re-assigning to correct owner if it is not related to your change. Thanks!
,
Oct 17 2017
Seems like the CPU usage of the page goes up to 100%. I don't know how to figure out what's going on. Maybe people more familiar with scheduling in the renderer can track the problem?
,
Oct 17 2017
,
Oct 17 2017
Compositor thread is stuck running Scheduler::BeginFrame while ProxyMain::BeginMainFrame::commit is blocking main thread waiting for compositor. We need compositor folks to take a look at this. Trace: https://drive.google.com/a/google.com/file/d/1qympm_JYllMPfsRvko3xkyXUKM1ZuWuK/view
,
Oct 17 2017
There are weird flags being used here, right? (e.g., disabling vsync)
,
Oct 17 2017
No, I was able to repro these issues locally without any flags.
,
Oct 17 2017
From the trace, it looks like: 1) Compositor draw attempts takes more than entire vsync period. 2) NotifyReadyToCommit takes a really long time to make it to the compositor thread from the blink thread. I suspect there's a backlog of BeginFrames queued somewhere (due to the slow draws) that is starving the NotifyReadyToCommit.
,
Nov 30 2017
If it is of on any help, removing CSS loader fixed the problem. Though was wondering why. One thing, that CSS loader alone was taking a lot of CPU time.
,
Mar 2 2018
#0 can you still reproduce this? I couldn't repro on canary 66.0.3357.0 on mac.
,
Mar 29 2018
Marking as fixed as I can't repro this anymore. Please reopen the bug if the problem still reproduces. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by nyerramilli@chromium.org
, Oct 5 2017