thexpaw@ Thanks for filling the issue...

Unable to reproduce the issue on reported chrome version 69.0.3497.100 using Windows 10. Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Navigate to https://www.wrike.com/
3. Dragged the elements around in "Organize everything you need to complete your project in one place"
As we are observed that performance is smooth

@Reporter: Request you to retry this issue with fresh profile without any extensions & apps or reset all the flags and let us know if issue still persists.

Thanks..!

Deleted: 891837.mp4 3.6 MB

	891837.mp4 3.6 MB View Download

Yeah I already tried it with a guest profile, which has no extensions and it still happened. Some other people also confirmed they could see the same issue, so it's not an issue unique to my setup/system.

I'm not sure how to get a consistent repro though.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Unable to reproduce this issue. 
Reporter: could you please provide a tracing record from chrome://tracing ?

Sure.

Deleted: trace_dev.json.gz 4.0 MB

trace_dev.json.gz 4.0 MB Download

Deleted: trace_test.json.gz 1.7 MB

trace_test.json.gz 1.7 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Gentle ping...

@ eirage: As per comment # 6 and comment #7, could you please have a look in to it for further triaging it. 

Thanks..!

Thanks for pinging me. 

From the trace it looks like the janky is because main thread is very busy. Maybe  it's due to paint or layout

+Blink>layout and Blink>paint to triage

Majority of time appears to be spent in updating layer positions and in hit testing according to trace. Unsure why either would be triggered by dragging.

Hit testing is part of tracking what's under the mouse so I'm not super surprised that's involved. Moving a layer around by dragging would require updating layer positions, so not surprising that's there.

No idea why it's particularly slow, however.

My bad, looks like it's indeed an input issue.

drag and drop events were not coalesced like mouse events.[1]
[1]https://cs.chromium.org/chromium/src/content/common/drag_messages.h?g=0&l=31

From the tracing it looks like the reporter are using a 1000Hz mouse, which will result in tons of ondrag and ondragover events. I can only reproduce this with a 1000Hz mouse but not a 125Hz one.
It's either because the hit test on drag events or the page are doing some layout on dragover events.

+navid, do you think we should plan to clean up the drag messages? 

I suspect this also affects dragging tabs in Chrome window itself. It's definitely not as laggy as the widget on the site, but it's noticeably not very smooth.

We might face some issues when coalescing drag events. Mainly because there is no alternative way for the page to get those non-coalesced events for drag events. But at the same time I cannot imagine a use case for getting the coalesced drag events.

Can the reporter also verify this hypothesis regarding the low vs high frequency mouse and whether the slowness goes away with low frequency mouse? Particularly since it is mentioned that it works fine on Edge, I wonder whether Edge does the coalescing. As far as I remember they weren't doing anything like that.

I just tried with a wireless mouse, which presumably has a low polling rate, and indeed I do not experience lag with it.