Able to reproduce the issue on Ubuntu 17.10 using chrome version #72.0.3616.0 and latest stable #70.0.3538.102. Issue is specific to OS-linux.

Bisect Information:
=====================
Good build: 69.0.3496.0
Bad Build : 69.0.3497.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/7a734fb249347d237070c0aacc420899cf422d99..5e35d8a8cb7c2547cd2d13e1b5ab283a112cf900

From the above change log suspecting below change
Change-Id: If77903b5b275f6d0deee6d22d88a3725885137f2
Reviewed-on: https://chromium-review.googlesource.com/1132543

pbos@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Likely mine. Marking as available since I don't have the cycles to fix this before M72 branch at least.

***UI Mass Triage ***

Still able to repro & seems it's a valid issue adding respective labels.

+pkasting this is expected behavior now, right?

Whenever the border is shown we should theme it. Is the border expected to be showing for Linux here even?

I'm actually planning on removing the border on Linux (bug 811515).

IIRC, pkasting mentioned that the frame image should no longer be tiled along the edges.

I think OpaqueBrowserFrameView can't be borderless on Windows7 w/ glass. I think it should be borderless on Linux though, or would that be weird?

Then this is a dup.

Not a dupe; the fact that we might remove Linux' frame borders doesn't address the question of how they should appear when they aren't removed, especially given that on Windows non-Aero we don't currently have plans to remove them.

However, this is WontFix.  We intentionally changed to not paint the frame image atop the borders because it's an enormous memory cost to keep a giant image in memory for painting different-size windows, for a rare case.  So we paint the borders with the frame color given in the theme, which can specify active vs. inactive and normal vs. incognito colors.

So these themes need to set an appropriate frame color in order to not look bad.  If they set no frame color at all, we should auto-compute one based on the dominant color of the frame image, so the theme should only get bad behavior if it sets a frame color explicitly but that frame color is nothing like the frame image color.

The sad part about all this is that theme authors lack good documentation or tooling to tell them that and help them fix such problems.  I wish we provided it.  But as far as Chrome's behavior itself goes, this is working as intended AFAICT.