New issue
Advanced search Search tips
Starred by 7 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 10
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

requestIdleCallback is fired with inconsistent delays depending on user scroll

Reported by sall...@twitter.com, Feb 12 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce the problem:
Relevant JS fiddle: https://jsfiddle.net/zedt5szm/4/

Case 1:

1.  Click start (schedules 500ms of work, schedules an rIC)
2. Scroll down and up once
3. Wait for work to be completed and the rIC callback to be executed

Note the times: ~2285 ms after work done and ~2000 ms after most recent scroll event

Case 2:
1. Click start (schedules 500ms of work, schedules an rIC)
2. Scroll down and up repeatedly until work finished
3. Wait for work to be completed and the rIC callback to be executed

Note the times: ~1100 ms after work done and ~21ms after most recent scroll event

What is the expected behavior?

What went wrong?
Expect the rIC to be executed without a 2000ms delay. If the delay is expected, expect that the delay is consistent. It appears that more user scrolling can result in the callback being called sooner which seems unexpected.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.132  Channel: n/a
OS Version: OS X 10.13.3
Flash Version: 

Context:
This issue was surfaced in the Twitter Lite PWA @ mobile.twitter.com

The timelines use a virtual scroller and to reduce jank, we were scheduling the image fetch / decode on an rIC. This originally ensured that on lower end devices, the image fetch would be deferred until idle / scroll complete. With this scheduling delay however, there is now a minimum of 2000ms delay after the browser goes idle / user stops scrolling. We are working around this by supplying a timeout of 1000ms but this effectively becomes a setTimeout during scrolls of 1s or more.

I understand that there is no actual guarantee for when idle callback work will be executed but consistency on this matter would make it easier to make decisions on when to and not to use rIC. Furthermore, it would appear that other major browsers do not introduce this delay.
 
scroll ric demo.mp4
141 KB View Download
Labels: Needs-Triage-M63
Labels: Needs-Feedback
Tested the issue on chrome reported version 63.0.3239.132 using Mac 10.13.1 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://jsfiddle.net/zedt5szm/4/
2) Clicked on "Start" button and scrolled up and down once, Observed ~3314.11ms after work done and ~3049.99ms after most recent scroll
2) Again clicked on "Start" button adn scrolled up and down until call back is executed, Observed ~5193.14ms after work done and ~228.42ms after most recent scroll

@Reporter:
Please find the attached screencast for your reference, try to test this issue on latest stable (64.0.3282.167) and let us know if the issue still persists, if possible could you please provide the screen cast of excepted behaviour of the issue which helps us in further triaging it.
you can download latest stabel from URL provided, URL:https://www.chromium.org/getting-involved/dev-channel

Thanks!
811451.mp4
1.1 MB View Download
Labels: -Pri-2 Pri-1
This delay is the result of an intervention by the Blink Scheduler aimed at reducing scrolling jank: for a certain period (2 seconds) after the last scroll a subsequent scroll is expected and long timer and loading tasks.

The fact that the idle tasks are being delayed too seems like a bug which we should fix.

We're having problems reproducing this, could you share a trace with us? Instructions are here: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs, please include toplevel, benchmark, blink, renderer.scheduler and disabled-by-default-renderer.scheduler categories.

Comment 4 by sall...@twitter.com, Feb 22 2018

I will run the trace and update tomorrow, thank you
Project Member

Comment 5 by sheriffbot@chromium.org, Feb 22 2018

Cc: viswa.karala@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: krajshree@chromium.org
Labels: Needs-Feedback Triaged-ET
As per comment #4, adding label Needs-Feedback.

Comment 7 by sall...@twitter.com, Feb 23 2018

I'm no longer able to reproduce the inconsistency based on how the user scrolls on Chrome 64. However, while the inconsistency is fixed, the minimum 2s delay on idle tasks is still problematic. I'm not sure I understand what you mean by 

'for a certain period (2 seconds) after the last scroll a subsequent scroll is expected and long timer and loading tasks.'

Are you saying that it is expected for the idle tasks to be delayed till scrollEnd + 2s?

Given that I can't repro the inconsistency in 64, I haven't run the timeline trace but I can if you think it still has value.

Thank you for time  altimin@chromium.org
Project Member

Comment 8 by sheriffbot@chromium.org, Feb 23 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by sall...@twitter.com, Feb 23 2018

I believe the video that viswa.karala@chromium.org posted shows the idle delay issue in Chrome. For comparison, here's firefox: 
ff idle.mov
278 KB View Download
Cc: susan.boorgula@chromium.org
 Issue 822269  has been merged into this issue.
Labels: -Pri-1 M-68 FoundIn-68 Target-68 Pri-2
Status: Untriaged (was: Unconfirmed)
Tested the issue on Windows 10 and Mac OS 10.12.6 on the latest Stable 66.0.3359.170 and Canary 68.0.3427.0 and unable to reproduce the issue.

As per comment #10,  issue 822269  is duped into this issue.
As we were able to reproduce the  issue 822269  and marked it as Untriaged, marking this issue as Untriaged as well and requesting Dev to look into this and help in further triaging.

Thanks..
The JS fiddle provided by the marked as dupe ticket shows this issue much more clearly:  https://jsfiddle.net/zjzm75qL/28/ thanks 
Labels: Needs-Feedback
Status: Unconfirmed (was: Untriaged)
The jsfiddle seems to be working correctly on M69. Are you still seeing problems here? For the 2s delay specifically, it should now only show up if you have scroll blocking touch handlers on the page.
Status: WontFix (was: Unconfirmed)
Mac triage: WontFix issue without feedback - please reopen if you still see this.

Sign in to add a comment