I will add that the error (regression) takes place both under Archlinux and Debian Stable. With the fact that under Arch once every 3-4 Chrome launches, the error disappears. The message from the console then looks like this:

[368:368:1008/135118.450006:ERROR:gpu_process_transport_factory.cc(980)] Lost UI shared context.
[1:8:1008/135118.777599:ERROR:command_buffer_proxy_impl.cc(100)] ContextResult::kFatalFailure: Shared memory region is not valid

When there is an error:
[1:8:1008/141744.727822:ERROR:command_buffer_proxy_impl.cc(119)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.

The last good build.
https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F583547%2Fchrome-linux.zip?generation=1534397474229317&alt=media
First bad.
https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F583549%2Fchrome-linux.zip?generation=1534398022418261&alt=media
It's strange that for almost two months nobody has seen it.

Thanks for filing the issue.

Unable to reproduce the issue on reported chrome version #71.0.3559.6 using Ubuntu 17.10, by following steps as per screencast in comment#0.

@reporter: Could you please specify if this is the issue is specific to Arch Linux and Debian so that it would be really helpful in further triaging of the issue.
Thanks.!

This is how it looks at Debian Stretch under Google Cloud Shell (I know, I know he does not do it). VNC session.

Deleted: debian.mp4 1.2 MB

	debian.mp4 1.2 MB View 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

The 583547-583549 range reported in #0 has two commits:
https://chromium.googlesource.com/chromium/src/+log/b54dfd4d..052ff32c
Suspecting r583548 "Enable Viz Display Compositor on perf bots"

Reporter, see if the bug disappears when running chrome with "--disable-features=VizDisplayCompositor" command line.

When I started Chrome (beta, devel) with this option (--disable-features=VizDisplayCompositor), the problem completely disappears (both under Arch Linux and Debian Stretch).

 grapeli23@Thanks for the feedback...

@Reporter: As per comment #7 and comment#8, Can you please confirm that we can close this issue or not. Adding Needs-Feedback label to it.

Thanks..!

re #9, no, it means Chrome is buggy in its default state, and the bug disappears only when this feature is disabled. I guess you can CC/assign the author of r583548, fsamuel@chromium.org.

For me, the problem has disappeared after disabling this feature.
chrome://flags/#enable-viz-display-compositor

I already know what to turn off, but will other Chrome 70 users be?
Thanks for the help.

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

I mentioned it earlier, it surprised me that nobody has noticed anything similar for almost two months. I waited.
Maybe it concerns a very small group of users. I'm guessing, those without any graphics acceleration, which is very rare on the "desktop".

Tentatively adding Internals>Services>Viz component to it and cc'ing: Fady Samuel to help in providing further inputs on this issue.

Thanks!

As per comment# 14, adding TE-NeedsTriageHelp label to it and requesting someone form Internals>Services>Viz component team help in providing further inputs on this issue.

Thanks!

Able to reproduce the issue on latest chromium stable #70.0.3538.102,reported chromium version #71.0.3559.6 and latest chromium version #72.0.3610.0 by using Ubuntu 17.10 and Mac OS 10.14 by following steps as per comment#0. 
Note : Issue is not seen on Windows.

As per comment#7  assigning to Fady Samuel and below is the Changelog URL.
Change Log: "https://chromium.googlesource.com/chromium/src/+/209e15b44e0c2c2d127b5c9a4416b996d663cc5e"
Reviewed On: "https://chromium-review.googlesource.com/1161554".

@Fady; Please help us in reassigning the issue if it is not related to your change.
Thanks.!

OOP-D seems to have regressed tooltips.

I can reproduce on Linux. I'll investigate and get that fixed ASAP.

swarnasree.mukkala: I cannot reproduce this on mac. Can you double check if it reproduces on mac and if so record a video of it? Thanks.

SoftwareOutputDeviceX11 needs to flush the output buffer, so a simple fix and can be merged back to M71.

In reply to comment#18.

@kylechar: Besides theme setting, while checking the issue on Mac OS 10.14 observed that the tooltips appear with some delay and considered this as bad behavior and added OS-Mac label. hence removing Needs-TestConfirmation.

Please find the attached screencast.
Thanks.!

Deleted: 892110(Mac).mp4 496 KB

	892110(Mac).mp4 496 KB View Download

Removing mac label as that looks correct to me. It's the initial blank tooltip on Linux that is problematic.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cb5adf205586281beb5b13bf8f48319687b2cf23

commit cb5adf205586281beb5b13bf8f48319687b2cf23
Author: kylechar <kylechar@chromium.org>
Date: Thu Nov 15 22:33:36 2018

Call XFlush() for X11 software compositing.

With OOP-D and SoftwareOutputDeviceX11 being moved to the GPU process
sometimes tooltips aren't showing up immediately. Instead an empty
tooltip window appears until something else happens that causes GPU
process to flush it's output buffer. Add call to XFlush() to prevent
this.

Bug:  892110 
Change-Id: I2aba6b9e41286ff6de9a68864d412b45cdcc7345
Reviewed-on: https://chromium-review.googlesource.com/c/1335999
Reviewed-by: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608554}
[modify] https://crrev.com/cb5adf205586281beb5b13bf8f48319687b2cf23/components/viz/service/display_embedder/software_output_device_x11.cc

I tested version 72.0.3613.0 and it now works as it should.

Able to reproduce the issue on chrome version# 710.0.3538.0 using Ubuntu 17.10 by following steps as per comment#0.

Verified the fix on Ubuntu 17.10 as per comment#0 on latest chrome version #72.0.3612.0.
Attaching screencast for reference.
Observed that the tooltips appear immediately.
Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Deleted: 892110(CL) 1.2 MB

892110(CL) 1.2 MB View Download

++ Correction in comment#24

Able to reproduce the issue on chromium version #70.0.3538.0 and verified fix on chromium version #72.0.3612.0.

This should be safe to merge into M71. Will give it a bit of time to see if anything unforeseen happens then merge back.

Merge request for #22. This change fixes an issue when VizDisplayCompositor experiment is turned on and tooltips don't show up immediately. The fix is unlikely to cause any problems and only impacts Linux.

Approving merge to M71 branch 3578 based on comment #26 and #27. Please merge on Monday morning. 

The NextAction date has arrived: 2018-11-19

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/50b9e973d0ae22cfbe5ee194926c693e7abad645

commit 50b9e973d0ae22cfbe5ee194926c693e7abad645
Author: kylechar <kylechar@chromium.org>
Date: Mon Nov 19 14:17:23 2018

Call XFlush() for X11 software compositing.

With OOP-D and SoftwareOutputDeviceX11 being moved to the GPU process
sometimes tooltips aren't showing up immediately. Instead an empty
tooltip window appears until something else happens that causes GPU
process to flush it's output buffer. Add call to XFlush() to prevent
this.

Bug:  892110 
Change-Id: I2aba6b9e41286ff6de9a68864d412b45cdcc7345
Reviewed-on: https://chromium-review.googlesource.com/c/1335999
Reviewed-by: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608554}(cherry picked from commit cb5adf205586281beb5b13bf8f48319687b2cf23)
Reviewed-on: https://chromium-review.googlesource.com/c/1340513
Cr-Commit-Position: refs/branch-heads/3578@{#749}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/50b9e973d0ae22cfbe5ee194926c693e7abad645/components/viz/service/display_embedder/software_output_device_x11.cc

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/50b9e973d0ae22cfbe5ee194926c693e7abad645

Commit: 50b9e973d0ae22cfbe5ee194926c693e7abad645
Author: kylechar@chromium.org
Commiter: kylechar@chromium.org
Date: 2018-11-19 14:17:23 +0000 UTC

Call XFlush() for X11 software compositing.

With OOP-D and SoftwareOutputDeviceX11 being moved to the GPU process
sometimes tooltips aren't showing up immediately. Instead an empty
tooltip window appears until something else happens that causes GPU
process to flush it's output buffer. Add call to XFlush() to prevent
this.

Bug:  892110 
Change-Id: I2aba6b9e41286ff6de9a68864d412b45cdcc7345
Reviewed-on: https://chromium-review.googlesource.com/c/1335999
Reviewed-by: kylechar <kylechar@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: kylechar <kylechar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608554}(cherry picked from commit cb5adf205586281beb5b13bf8f48319687b2cf23)
Reviewed-on: https://chromium-review.googlesource.com/c/1340513
Cr-Commit-Position: refs/branch-heads/3578@{#749}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

Able to verify the fix on latest chromium(#72.0.3612.0) as mentioned in comment#24. The issue is specific to chromium and we are unable to download the branch builds of the chromium. Hence we could not verify the fix on the latest M-71 (#71.0.3578.62).

Thanks.!

Based on offline chat with Kyle, we don't need any verification here on M71.