Thanks for filing the issue!

Unable to reproduce the issue on chromium version 70.0.3538.0 using Ubuntu 14.04 with the below mentioned steps.
1. Launched Chromium
2. Searched some random content
Didn't notice any freeze in the UI.

@Reporter: Could you please check the same in a new profile without apps & extensions and let us know if the issue still persists.

I tried removing config and fresh install but issue persists. It happens on both chromium and chrome on two different laptops with identical setups (Arch + KDE Plasma). I thought that problem is gpu related so I tried disabling hw accel and similar recommendations for UI lag. But two laptops have different gpus, one has dedicated nVidia and other has integrated intel graphics. I also have PC with Arch and Gnome where it works just fine.

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

This issue also occurs on my system whenever Chromium is trying to display a **multiline** tooltip message for the first time after it was launched. I can reproduce this on a fresh profile via --user-data-dir and then opening the dev tools and adding a multiline tooltip (title DOM property) on an element on the welcome page and hovering it. This also happens in various NW.js and Electron apps, hence a Chromium issue.

OS: Arch Linux
DE: Cinnamon
Chromium: 70.0.3538.102 (stable)

Btw, OP created this bug report after posting a thread on Reddit's /r/archlinux. Someone in there mentioned that this might be related to the fonts on the user's system. I hope it's okay if I link it here:
https://www.reddit.com/r/archlinux/comments/9wnur4/chromium_and_googlechrome_lag_problem/

Unable to reproduce the issue on reported chromium version #70.0.3538.102 using Ubuntu 17.10(Gnome), as per comment #5 the issue seems to be related to Arch Linux.

Hence requesting someone from Inhouse team to test the issue on Linux flavor which is present there, tentatively adding TE-NeedsTriageFromHYD.
Thanks.!

Unable to reproduce the issue on reported chromium version #70.0.3538.102 using Debian rodete, as per comment #5 the issue seems to be related to Arch Linux.

As Arch Linux is not available with Google-Hyd team , adding TE-Hardware-Dependency label to investigate further.

Thanks!

Same on Ubuntu 18.04

Mouse: Logitech G403
Keyboard: Quick Fire TK

Can one of you experiencing this issue record "a trace"?  This should show what's causing the delays.
https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

thanks!

Sorry for the late response, here is a full trace log. This is what I have done (as described in #5):
I opened Chromium 71.0.3578.98 with a fresh data-dir and positioned the mouse pointer outside of the window so it doesn't accidentally trigger any initial freezing UI action, pressed F12 to open the dev tools on the welcome page, pressed ESC to toggle the console and pasted the following into it:
document.querySelector("welcome-app").title="foo\nbar"
Then I opened chrome://tracing in a new tab via CTRL+T and F6, started a full trace log, switched back via CTRL+TAB, executed the code and hovered over the welcome-app element, which caused Chromium to freeze for a couple of seconds and then stopped the trace log.

Deleted: trace_Sat_Dec_29_2018_6.55.27_PM.json.gz 2.2 MB

trace_Sat_Dec_29_2018_6.55.27_PM.json.gz 2.2 MB Download

brucedawson@ (I spotted your name somewhere this week): can you route this appropriately to someone who can interpret the trace?

Thanks bastimeyer123@ for the trace!  Hopefully it'll help.

Looking at the GPU process I see an invocation of GpuCommandBufferMsg_AsyncFlush that took a while to run due to multiple calls to GLES2DecoderImpl::DoLinkProgram. That lasted 108 ms which is slow, but not long enough to account for the reported freezes.

Then I noticed a 5.145 s block where CPU time was steadily being consumed but there was mostly no activity. During that time the only task running was Scheduler:pending_submit_frames. I'm not clear on the details but it seems that a 5.1 second delay to submit a frame is the problem, and this must almost certainly be a GPU problem, probably driver problem, despite the attempts to isolate that factor.

I've attached a screenshot of the trace with the two relevant areas circled.

I'm tagging this as Internal>GPU and making it available because I can't offer any more guidance.

Deleted: Five second frame.PNG 122 KB

	Five second frame.PNG 122 KB View Download

In case it's needed, attached to this post is the output of chrome://gpu.
And also again some basic details:
OS: Arch Linux
DE: Cinnamon
Chromium: 71.0.3578.98-3 (Arch's default "chromium" package)
GPU: Nvidia GTX 560ti
Driver: nvidia-390xx-dkms 390.87-25 (legacy branch for Fermi GPUs)

Deleted: chromium-gpu-debug.txt 14.8 KB

chromium-gpu-debug.txt 14.8 KB View Download

Looking at the trace, it appears that this is font related. The renderer hang is probably a consequence of the browser being completely blocked, not the source of the issue.

If you look at CrBrowserMain thread between 4 and 9 seconds, RenderTextHarfBuzz::ShapeRuns is blocking the browser process with 5s of active CPU work.

Seems font related. etienneb@ can you take a look?