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

Issue 633188 link

Starred by 5 users

Issue metadata

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



Sign in to add a comment

setTimeout only fires after scrolling is done when the timer is set in a scroll event handler

Reported by thomas.s...@ligadigital.com, Aug 1 2016

Issue description

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

Steps to reproduce the problem:
1. Attach a scroll event listener to a scroll event
2. Call a function that does some kind of expensive work with a setTimeout within the scroll event listener
3. Scroll a lot in the container with the attached event handler
4. The function will be called for the first time a few seconds after the scrolling ends

A small reproduction can be found here: https://jsbin.com/zozurecixi/1/edit?html,output

What is the expected behavior?
The function should be called earlier like in other Browsers and in Chrome 51.

What went wrong?
The function that was given to setTimeout is called a few seconds after the scroll events happened and only after scrolling ends completely.

Did this work before? Yes Chrome 51

Chrome version: 52.0.2743.82  Channel: stable
OS Version: OS X 10.11.5
Flash Version: Shockwave Flash 22.0 r0

As you can see in the reproduction, when you scroll around for a while, the 'timeout' and the result of the function only gets logged to the console after you stopped scrolling for a while. This issue only appears since Chrome 52 and isn't observable in other browsers.
Setting the event handler to passive doesn't change the behaviour.
 

Comment 1 by kochi@chromium.org, Aug 2 2016

Components: -Blink Blink>Input
Owner: rbyers@chromium.org
Status: Available (was: Unconfirmed)
Can anyone in input team take a look for this?
Cc: tdres...@chromium.org
Components: Blink>Scheduling
Owner: ----
Status: Untriaged (was: Available)
to input-dev triage queue (though is probably scheduling, so adding that label too).
Cc: alexclarke@chromium.org
Owner: skyos...@chromium.org
Status: Assigned (was: Untriaged)
Over to Sami for triage.
I think this is working as intended: the browser is prioritizing[1] the scroll gesture over a long running piece of Javascript to avoid jank in the animation.

If you want the work happen during a scroll, probably the best way is to use requestIdleCallback[2] instead of setTimeout. It will let you do processing cooperatively without affecting animation frame rate. For best results I suggest splitting up the expensive work into smaller incremental chunks.

[1] https://docs.google.com/document/d/14VdbqN-ehgpNC4KYVpPQFiQpfxOQiVtJgYjXUJGI4f0/edit
[2] https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
Status: WontFix (was: Assigned)
Labels: Hotlist-Input-Dev

Sign in to add a comment