setTimeout and setInterval pause under specific conditions
Reported by
sco...@wordpressoverwatch.com,
Feb 20 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. Attached is a chrome extension and a example website. Go ahead and install the chrome extension. All it does is call chrome.runtime.setMessage() after a 0-second timeout. 2. Load up the example page. You should see a flashing box. This box's flashes are timed using the setInterval function. There's also an (empty-function) event listener tied to onTouchStart. 3. Open dev tools. Change it to mobile view. Under performance>options gear>CPU set it to 6x slowdown. 4. Refresh the page. The bug mostly happens exclusively within the first 20 seconds of the page load. 5. Scroll by click-dragging. You should see the animation stop, and stay stopped until a little after you let go. What is the expected behavior? The setInterval shouldn't stop running. What went wrong? The setInterval, (and setTimeout if you were to test it) stop working while your mouse is down. Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: Fedora 27 Flash Version: N/A I found this problem while working on a react website. The react-dev-tools extension helped create the problem, however I've also been able to reproduce the problem with extensions disable, and without CPU throttling which suggests that there's more than one way to make the problem happen.
,
Feb 21 2018
If you have touch event handlers on your page, Chrome can occasionally decide to defer expensive timers on the page to reduce touch latency. You can work around this by making your timers less expensive (ideally <16ms on average) or by making the touch event listeners passive.
,
Feb 21 2018
While its true that in this scenario I am throttling the CPU, I don't think chrome is purposefully postponing the timeouts due to the touch event because 1. If you look at the code, you'll see that I did infact make the touch event listener passive, plus the listener is an empty function. 2. I might be wrong here, but doesn't chrome put warnings in the dev tools when it desides an event listener is running to slow? 3. It's not that the setInterval is running to long either, The same thing can be repeated using console.log instead of css updates, and you can freeze still freeze the callbacks for as long as you keep your finger on the screen. 4. If you record performance with the dev tools while during the scrolling, you'll see that it really isn't taking up any resources.
,
Mar 2 2018
So... any thoughts? Is it really Chrome deferring the event listeners? Or is there actually a bug?
,
Mar 14 2018
Any update on this? I did spend a long time trying to narrow down the bug, it would be nice to know if it really is a bug or not. |
||
►
Sign in to add a comment |
||
Comment 1 by ajha@chromium.org
, Feb 20 2018