React-virtualized: Delay in hover and click

Created on 6 Feb 2017  路  9Comments  路  Source: bvaughn/react-virtualized

React-virtualized breaks hover events in Grid. This means that cell can be hovered or clicked with delay after rendering it.

After debugging it truned out that setTimeout method in Grid.js file in react-virtualized (function _debounceScrollEnded) is not always working properly. After calling setTimeout with timeout=0 or 1 (or any other value) the callback (_debounceScrollEndedCallback) method was triggered with 1.5 to 2 seconds delay. What is more when I tried to call setTimeout (timeout=1ms) with simple concole.log message was also printed with long delay. I can see the problem on Chrome 55.0.2883.87 (64-bit) on Ubuntu 16.04.1 LTS. I also tried the same version of Chrome in Windows and could not reproduce the problem. The problem was not reproducible on Firefox.
I decided to report it here because I am not sure if this is a problem in React Virtualized or this is browser problem.

Most helpful comment

setTimeout doesn't guarantee a callback will be invoked exactly after the specified delay- only that it won't be invoked before then. The Mozilla's docs list a few reasons why the callback may be delayed, including:

I understand that but how one can explain 1.5-2 seconds delay if browser is idling (I used timeline which showed zero browser activity for 1.5-2 seconds) + zero activity on any of 4 CPU cores.

Thanks for explaining and information that I can disable pointer-events. I think it make sense to keep it disabled when scrolling. It is just annoying that the delay is so long. 2 seconds sounds like "ages" :)

All 9 comments

After calling setTimeout with timeout=0 or 1 (or any other value) the callback (_debounceScrollEndedCallback) method was triggered with 1.5 to 2 seconds delay.

setTimeout doesn't guarantee a callback will be invoked exactly after the specified delay- only that it won't be invoked _before_ then. The Mozilla's docs list a few reasons why the callback may be delayed, including:

In addition to "clamping", the timeout can also fire later when the page (or the OS/browser itself) is busy with other tasks

There's also blog posts like this one:

The scheduler now delays impending expensive timers after a tap in anticipation of these tasks, allowing many web pages to be scheduled more efficiently. In practice, this can result in up to a 50% input latency improvement on websites that use timers heavily.

As for why I disable pointer events in the first place~ Grid (and so List and Table as well) intentionally disables pointer-events while a user is scrolling. This is a common technique in windowing libraries (see react-infinite's Infiniteand fixed-data-table's FixedDataTableBufferedRows).

I believe this is the correct default approach for performance reasons. However if you disagree that it's appropriate for your app then you can override by passing in your own containerStyle that sets pointer-events: "auto".

I'm going to close this issue for now as it doesn't seem directly actionable. We can continue to chat here (or on Slack) though if you have more ideas or questions. 馃槃

setTimeout doesn't guarantee a callback will be invoked exactly after the specified delay- only that it won't be invoked before then. The Mozilla's docs list a few reasons why the callback may be delayed, including:

I understand that but how one can explain 1.5-2 seconds delay if browser is idling (I used timeline which showed zero browser activity for 1.5-2 seconds) + zero activity on any of 4 CPU cores.

Thanks for explaining and information that I can disable pointer-events. I think it make sense to keep it disabled when scrolling. It is just annoying that the delay is so long. 2 seconds sounds like "ages" :)

I understand that but how one can explain 1.5-2 seconds delay if browser is idling (I used timeline which showed zero browser activity for 1.5-2 seconds) + zero activity on none of 4 CPU cores.

That sounds more like a question for the browser vendor. (I don't know.)

I agree that it's annoying for pointer events to stay disabled for so long. 鈽癸笍

OK so in your opinion it could be a kind of Chrome bug, right? As I mentioned in my first message I didn't know if I should blame Chrome for it or not. That's why I opened an issue. Thanks a lot once again.

Afraid I don't know enough to call it a _bug_ just that it's probably a question for someone who knows more about Chrome internals than me.

And you're welcome. Not a problem. 馃槃

FYI related discussion on #529

@prog8 I have the exact same problem. The browser seems to be idling for a few seconds after the scrolling event disabling all hover actions on the table. Have you found a solution to the problem yet? Pls keep us updated once you find something.

+1 same issue here

Potential solution here: #722
Just waiting for a contributor 馃槃

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pkumar84 picture pkumar84  路  4Comments

athorwall picture athorwall  路  4Comments

bee0060 picture bee0060  路  3Comments

ellatrix picture ellatrix  路  3Comments

hyeminHwang picture hyeminHwang  路  3Comments