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

Issue 609140 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 597006
Owner: ----
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Idle Task is indefinitely delayed when there is no mouse movement from users

Project Member Reported by xlai@chromium.org, May 4 2016

Issue description

We notice that idle task is not getting invoked at all when there is no users' mouse movement in browser, when we were fixing a user-reported bug here (https://bugs.chromium.org/p/chromium/issues/detail?id=606796) about canvas.toBlob (Note that canvas.toBlob is the only user-facing API that relies on idle task). We had fixed the problem by switching canvas.toBlob to execute on non-idle task when the idle task is delayed for too long (https://codereview.chromium.org/1938103002); however, the problem about idle task mechanism needs to be inspected by the scheduler team.

Instructions on how to reproduce the problems:

1. Apply this patch (https://codereview.chromium.org/1945903003) into your code. This is a patch that I wrote to demonstrate this problem.

2. Compile "ninja -C out/Debug chrome". Open the browser "out/Debug/chrome".

3. Paste this weblink (http://codepen.io/anon/pen/RaYVwr/) into the address bar of the browser. This is a simple JavaScript that once you clicks "Blobify" button, the canvas.toBlob will get invoked. Wait until the big canvas is loaded and you see the picture.

4. Now watch the console window. Click the "Blobify" button, and immediately after clicking the button, keep hovering your mouse movement constantly (but no scrolling).

Observation: Then you can see the Idle task is posted, beginning to initiate, paused (due to idle task deadline approaching, it will re-post another idle task to continue), and continued from previous paused state, and eventually you see "Idle task completed". Everything is good, although the idle task seems to be re-posted for too many times, but it makes sense because user mouse movement is super busy in this case. 

5. When you see the alert window popping up "done", it means the whole canvas.toBlob process is done (either via idle task or via non-idle task). Close the alert window.

6. Now try a different approach. After clicking the "Blobify" button, do not move your mouse at all (Keep your hand steady!). Just wait and watch the console window.

Observation: you will see either "Idle task starts too slow! Have to switch to non-idle task at StartTimeoutEvent" or "Idle task paused for too long! Have to switch to non-idle task at CompleteTimeoutEvent". That means the idle task never get executed (in the first printout statement) or the idle task get executed but when another idle task is re-posted it never get executed to continue from previous paused state (in the second printout statement).

7. Close the alert window that displays "done" and repeat step 4 or step 6.



Conclusion: When the main thread is super busy (having lots of user mouse movements), the idle task is working well. When the main thread is idle (no user mouse movement at all), the idle task is supposed to act super fast; but in reality, it does not get executed. This is abnormal. Please investigate.















 

Comment 1 by xlai@chromium.org, May 4 2016

Typo: "the only user-facing API that relies on idle task" should be changed to "one of the few user-facing API that relies on idle task". I'm sure the similar problem can be reproduced on Window.requestIdleCallback but I haven't tried on that yet.
Mergedinto: 597006
Status: Duplicate (was: Available)
Thanks for the repro case!

Sign in to add a comment