Also, the janks on IO thread seem to be here:

src_file	
"../../../../../../../home/chrome-bot/chrome_root/src/net/http/http_stream_factory_impl_job.cc"
src_func	
"RunLoop"

here's another trace (loading arstechnica this time) with network tracing enabled.

Deleted: trace_mouse_jank_net.json.gz 4.0 MB

trace_mouse_jank_net.json.gz 4.0 MB Download

It looks like the RunLoop mostly calls to PostTask.

Ben, I started looking into where PostTask goes, but it looks pretty complex. Do you know how to trace this? How to debug what's taking a lot of time? Part of me wonders if it's going to end up at a call to malloc() blocking.

If you enable ipc.flow events in chrome://tracing then you should see flow events that show who is posting these events to the IO thread.

Also, if you enable the "net" tracing category then you'll see trace events from http_stream_factory_impl_job.cc that will hopefully make it clear what function is taking long.

If it's not clear from these trace events then just sprinkle more trace events in http_stream_factory_impl_job.cc until we know exactly what part is costly.

Here's trace w/ ipc.flow on, but I don't see how to see the new data.

Deleted: trace_mouse_jank_ipcflow.json.gz 2.6 MB

trace_mouse_jank_ipcflow.json.gz 2.6 MB Download

View Options -> Flow events [x] should be enough but you might have to also enable "net" category for this to work.

Here's the latest trace. I didn't see "Flow events" exactly, but I did input latency, then toggled on every option that had ipc, flow, or net in the name, except for sandbox_ipc. I'm looking now. I do see that PostTask is indeed taking a very long time now, but I don't see why.

Deleted: trace_mouse_jank_flow2.json.gz 7.3 MB

trace_mouse_jank_flow2.json.gz 7.3 MB Download

Attached screenshot shows the relevant part but it looks like there's no tracing in http_stream_factory_impl_job.cc for that task. We just needs to add more trace events to tasks posted from HttpStreamFactoryImpl::Job::RunLoop to track down what's going on here.

Deleted: net-flow.png 46.5 KB

	net-flow.png 46.5 KB View Download

+networking folks

Seems like the most likely culprits are SSL and QUIC, though there are certainly plenty of other possibilities.  Does seem a bit off that Job::RunLoop is at the top of the stack, instead of some socket callback - that hints a bit more at QUIC and H2 rather than SSL.

Actually, this could be due to  issue 678768 , which was fixed in 57.0.2978.0 / 56.0.2924.60.

Okay, I've updated and now I'm past that version. I will see if I can repro, but it will probably be a day or so before the bug comes back

Archiving due to lack of followup.