Tested on Windows 10 using chrome M54 #54.0.2840.87 and didn't observe any hit test events in timeline. Followed the steps given in comment #0 .

Attached screenshot for reference.

Could you please provide us the screenshot of the hit test events, as you haven't attached any in comment #0.

Thanks!

Deleted: 662030.png 437 KB

	662030.png 437 KB View Download

I just attached a screenshot mentioned in the issue description. To see 'Hit test' events in the timeline you might have to 'zoom in' timeline by mouse wheel as additional step to reproduce.

Actually, you screenshot also shows this issue. In a pie chart in the screenshot you provided we can see that most of the time browser spent on 'Rendering' step. 'Hit testing' is also categorized by Chrome as 'Rendering' so we see the same issue on your screenshot.

Can you please re-check to classify this issue?

Deleted: hit_test_timeline.png 53.5 KB

	hit_test_timeline.png 53.5 KB View Download

Able to reproduce the issue on windows-7 using chrome stable version 54.0.2840.87 and  canary 56.0.2910.0

This is regression issue broken in M50.Please find the bisect information as below
Narrow Bisect::
===============
Good ::50.0.2625.0   --   (build revision 370090)
Bad:: 50.0.2626.0 --   (build revision 370259)

ChangeLog: 
================
https://chromium.googlesource.com/chromium/src/+log/5dc7e9437e00c35c6fa2d30f365824b8f96b778b..883acd6a5e0d3effbd7420926ee4f592e4525bf8



Possible suspect
==================
f9fc6aeef30d310d1f03818ff187add0f60d32eb	


Review URL: https://codereview.chromium.org/1592973002


sergeyv@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue.

Thanks,

Just for your information: today I just downloaded Chrome 50.0.2624.0(which is older than shown in previous comment) and the problem already there - please look at the attached screen shot. Maybe this issue is non-regression or appeared much earlier?

Deleted: chrome_50.0.2624.0.png 198 KB

	chrome_50.0.2624.0.png 198 KB View Download

Still able to reproduce the issue on Win 10.0 using latest chrome version 57.0.2926.0.

sergeyv@ Could you please look into this issue.

Thanks!

Alph, could you please take a look?

Doesn't look like DevTools bug. DevTools just show the truth here.

Assigning this to myself to see if it's related to 676764, that I am fixing.

As per comment #10, removing the Needs-Bisect label.

Thanks...!!

The demo of another use-case where this issue is prevalent: https://jsfiddle.net/bb4ggpaL/1/

I found a solution for the "hit test"-problem which works in the examples given in the initial post and in comment#12.

Step 1)
Add the following css:
html, body{width:100%;height:100%;overflow:hidden;}

Step 2)
Add a wrapper-div and place the huge amount of elements within

Step 3)
Add the following css to the wrapper:
#wrapper{z-index:-1;position:relative;}

You'll no longer encounter any hit-test performance issues in the developer tools on mousemove. However, all elements within the wrapper will become inaccessible to event-listeners (click, touch, mouse).

In cases where you either just need to drag things around (a game-map) or the control is handled by the keyboard alone, that solution will solve the problem entirely, as the you can still attach event-listeners for the mouse and keyboard to the document instead.

Oh, and here is a demonstration of the solution:

Original: https://jsfiddle.net/58k80jth/
Solved: https://jsfiddle.net/7k2ndbos/

Thanks, Kenny! I will try to check this solution in our project to see if it solves our problem. However, this issue still seems to be relevant since your proposed solution solves the problem only for specific case.