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

Issue 785979 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression

Blocked on:
issue 787862



Sign in to add a comment

touchstart listener delays requestIdleCallback

Reported by mateusz....@allegrogroup.com, Nov 16 2017

Issue description

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

Steps to reproduce the problem:
1. Add a 'touchstart' event listener to the window.
2. Add a 'scroll' event listener to the window.
3. In 'scroll' listener callback use requestIdleCallback to invoke some function, let's call it 'foo'.
4. Scroll a bit and stop (you can use mouse or finger but not keyboard).
5. 'foo' is called after 2000ms

What is the expected behavior?
5. 'foo' is called immediately (less than ~50ms)

What went wrong?
Even though the CPU is completly idle, 'foo' is called after a long time. AFAIR 2000ms is the default timeout for RIC in Chrome.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.94  Channel: stable
OS Version: OS X 10.13.1
Flash Version: 

Here's a sample code: https://jsfiddle.net/wgvbfz8n/4/ Output is like (top is more recent):

Waited 2003ms
Waited 2019ms
Waited 2036ms
Waited 16ms
Waited 34ms

I see no reason why Chrome should wait this long, especially on desktop, where the touchstart is not even fired. This hurts the performance of scroll-dependant features and libraries (such as "lazysizes") which use RIC internally. You can override the timeout https://github.com/aFarkas/lazysizes/issues/434 but it's just a workaround.

Actually 'scroll' listener is unrelated, if you invoke requestIdleCallback in a loop, then adding 'touchstart' listener still affects when the callbacks are called.
Scrolling with a keyboard (i.e. down arrow) works fine.
Doesn't work on Android (Chrome 62).
 
Labels: Needs-Triage-M62
Cc: divya.pa...@techmahindra.com
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Triaged-ET M-64 OS-Linux OS-Windows Pri-1 Type-Bug-Regression
Owner: skyos...@chromium.org
Able to reproduce the issue on the reported chrome version 62.0.3202.94 and chrome version 64.0.3272.0 using Mac 10.12.6, Ubuntu 14.04 and Win 10

Bisect info:
----------------------
Good build: 60.0.3104.0
Bad build: 60.0.3105.0 

You are probably looking for a change made after 473208 (known good), but no later than 473209 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/cc4d2c53f23d0e9a694ff7d7ec78c4e982b1f8fa..2e545f253b342d81a9c2c27a83a0d08a1a0ab3ed

Reviewed on: https://chromium-review.googlesource.com/506157

Suspecting same from changelog.

@Sami Kyostila: Please confirm the issue and help in re-assigning if it is not related to your change.

Thanks!




Status: Assigned (was: Unconfirmed)
Cc: skyos...@chromium.org
Owner: ----
Status: Available (was: Assigned)
The bug here is that we don't realize that the event listener is passive and still enable latency optimizations for non-passive listeners.
Blockedon: 787862
Project Member

Comment 6 by sheriffbot@chromium.org, Nov 28

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Sign in to add a comment