New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 647870 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 636405
Owner:
ooo
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

requestIdleCallback doesn't fire for 30 seconds

Project Member Reported by paulir...@chromium.org, Sep 16 2016

Issue description

We ran into this bug during a sync with the V8 team and wikipedia eng. 

While loading the wikipedia visual editor, they are scheduling work with rIC. Some of the callbacks don't fire anytime soon.

See attached screenshots.

On other runs we saw this gap can be smaller like 3.5s. But i repro'd a 30s gap twice.


Repro:
1. chrome on desktop
2. use keyboard only, no mouse
3. have mouse cursor outside of the chrome application window
4. open new tab
5. paste link: https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit
6. hit enter
7. wait

What you would expect is seeing a big blue progress bar starting.
With this bug, you will not see a big blue progress bar.

Repro'd on Stable and ToT. Both mac and linux.
 
overall.png
187 KB View Download
request IC at 13s.png
210 KB View Download
fire IC at 44s.png
128 KB View Download
Bisects reliably to: https://chromium.googlesource.com/chromium/src/+/14d4055bf0261e27d68ada55f540010f462187ea

So it has always been there...
Cc: skyos...@chromium.org
Owner: rmcilroy@chromium.org
Cc: krinklem...@gmail.com ttij...@wikimedia.org
cc wikipedia. You should absolutely use the polyfill 100% of the time until this bug in the native impl is fixed.

Comment 4 Deleted

Comment 5 Deleted

Blocking: 463348
Cc: rmcilroy@chromium.org junov@chromium.org xlai@chromium.org alexclarke@chromium.org
 Issue 597006  has been merged into this issue.
Owner: briander...@chromium.org
I took a look into this and made a trace (attached). There period where there are pending idle tasks, but not idle periods being scheduled between 8.5s to 29s.

The last idle period was a short idle period kicked off by a frame being committed (DidCommitFrameToCompositor). When this finishes we don't get any more frames, but we also don't get a BeginFrameNotExpectedSoon, so the scheduler doesn't start a long idle period.

At the 29s mark I moved the mouse in the window, which kicked off some more frames being drawn, and starts some short idle periods, after which we do get a BeginFrameNotExpectedSoon and so get long idle periods as expected.

The issue seems to be that the cc scheduler isn't sending the Blink scheduler a BeginFrameNotExpectedSoon when it should be, or that it sends a BeginFrameNotExpectedSoon, but then kicks off another frame for some reason (e.g, layout invalidation) which causes us to stop the long idle period, and doesn't send another BeginFrameNotExpectedSoon after this frame.

Brian/Sami - this is way beyond my knowledge of the cc scheduler. Could one of you take a look at this (assigned to Brian right now since Sami is OOO)? 
Actually attach trace
trace_requestIdleCallback.json.gz
8.3 MB Download
Cc: jochen@chromium.org
Chatted with Ross that this might be a bad interaction between BeginFrameNotExpectedSoon and retro frames.
Mergedinto: 636405
Status: Duplicate (was: Assigned)

Comment 13 by ebra...@gnu.org, Oct 14 2016

Blocking: -463348

Sign in to add a comment