Hmm.  I don't see anything nearly as bad as that glitch, but there is some kind of weird bug where tabs get drawn with the image starting at the wrong X coordinate sometimes.

 Issue 871779  has been merged into this issue.

Skia folks, can you give any help here?  This looks like some sort of Skia bug, maybe a new one or maybe a latent one exposed by changes in the offsets/mirroring of how we draw tab images.  This is pretty urgent to track down and fix.  How can I help do so?

(See the duped-in bug for another screenshot.)

+CC ccameron as someone who might have an idea or know who could investigate

(sorry, not sure!)

Here's a potentially related issue: Sometimes I see favicons glitch into black squares, which is similar to how I've seen the tab strip glitch on my Mac – everything either becomes all black, or has a very low alpha.

Deleted: Screen Shot 2018-08-10 at 4.58.09 PM.png 10.6 KB

	Screen Shot 2018-08-10 at 4.58.09 PM.png 10.6 KB View Download

re#c7: This looks like  issue 870317 . 

Agree, #7 is  issue 870317 , which is distinct from this issue.

+cc hcm@ for Skia triage

 Issue 885380  has been merged into this issue.

Actually not refresh -- per  bug 885380  this affects all versions of the UI.

Rob asked me to add that label so this would come up in their next meeting.

Adding the alternate label then.

One related defect I noticed while showing this to Rob:
The active tab background is "offset" (down?) from the inactive tabs and the window frame, perhaps via the stroke.
This breaks the alignment of the pattern in the window frame and the tab, see attachments.

Deleted: bg_offset_a.png 15.0 KB

	bg_offset_a.png 15.0 KB View Download

Deleted: bg_offset_b.png 14.6 KB

	bg_offset_b.png 14.6 KB View Download

Deleted: offset_zoom.png 35.0 KB

	offset_zoom.png 35.0 KB View Download

That's under the theme's control, but we haven't been very nice to theme authors here; until Chrome 69 it was impossible to create an active tab that was aligned with the frame in every possible case, and now that it's possible, the alignments are different in common cases than they used to be.  So the theme just needs to be updated here.

Users continue to report this.  How can we get traction here?  Can anyone reproduce this consistently?

On the current version of Chrome. Version 69.0.3497.100 (Official Build) (64-bit)

I have this bug but very much worse- consistently worse. This shows up around 98% of the time I middle-click for a new tab. When it doesn't show up, all I need to do is move over to a different tab and middle-click there instead. However, noteably, it doesn't happen for all themes. For example, if the theme has tabs that are a solid color, it doesn't happen- and it also doesn't happen for the theme "Morpheon Dark", although I'm not sure whether if it's because it's a theme that's actually been updated for Chrome 69, or if it's because it's something specific with the theme itself (specifically, the tabs themselves are a vertical gradient, which may mask the glitchy rendering. The theme I first noticed it on, meanwhile, had a significant horizontal gradient as a lighting effect, which only served to highlight the glitch.)

The following was what I originally wrote for another website (specifically, the Chrome subreddit). Also, do note that parts of it are out of date (noteably, I've fully switched over to Morpheon Dark at this point.):

"This mostly happens whenever I middle-click on a link in order to make it show up in a new tab, or open something in a new tab, something I do all the time during normal use. Instead of the tab looking normal, there seems to be a sort of graphical glitch where the tab's shading or texture or something is thrown way off. How buggy it looks kinda depends on the theme (themes that have the tabs be solid-color are completely unaffected), but the theme I've used literally ever since Chrome's themes were first released, Brushed, really makes it obvious... and I don't really want to switch to some other theme to fix this. (Also, switching to ANY tab after opening the new tab will fix already-existing tabs, but new tabs continue to exhibit the issue. And the New Tab button doesn't seem to have this issue... perhaps because it automatically switches you to itself?)"

I also placed an example screenshot (starring Brushed) in the attached image. Black bars are simply me censoring unimportant information and are not part of the graphical glitching.

Deleted: chromeglitch.png 89.3 KB

	chromeglitch.png 89.3 KB View Download

+ skia folks to help diagnose

@21: This theme? https://chrome.google.com/webstore/detail/brushed/bfjgbcjfpbbfepcccpaffkjofcmglifg

What's your OS version, video card, and driver version (just in case those are relevant)?

Skia folks: The code that actually draws that imagery is https://cs.chromium.org/chromium/src/chrome/browser/ui/views/tabs/tab.cc?sq=package:chromium&g=0&l=1261 .  I don't think the bug is at this layer or prior, because the image is getting drawn across the whole tab and the drawing call doesn't use different source/dest widths or the like.  The images in both comment 0 and comment 21 look more like something lower-level in how the image is being blitted is sample-and-holding.  Notably in comment 0 and comment 21 both I see the incorrect repetition being in blocks of 64 pixels wide, maybe there's some low-level loop based on working in rows of that length that's at fault?

I can reproduce this (on Mac, at ~head), only when opening background tabs.

It does look like an overlay image that's being stretched, perhaps interpreted as having the wrong dimensions.  I guess I'll start poking around to see if I can get a feel for what's being drawn how.

tl;dr This is an edge-case draw that Skia will definitely barf on, but I'm not really sure it was the draw you intended.

I've added a little LOG(ERROR) debugging,

  LOG(ERROR) << "fill_id="                   << fill_id                             << ", "
             << "active="                    << active                              << ", "
             << "scale="                     << scale                               << ", "
             << "src_x="                     << GetMirroredX() + background_offset_ << ", "
             << "y_inset="                   << y_inset                             << ", "
             << "img.width(),img.height()="  << img.width() << "," << img.height()  << ", "
             << "width(),height()="          <<     width() << "," <<     height();

and some of the results look pretty suspect, especially for the inactive tabs:

  ...
  [93884:775:0926/115829.343475:ERROR:tab.cc(1260)] fill_id=10495, active=1, scale=2, src_x=70, y_inset=1, img.width(),img.height()=120,121, width(),height()=256,35
  [93884:775:0926/115829.462163:ERROR:tab.cc(1260)] fill_id=10490, active=0, scale=2, src_x=-1094795347, y_inset=0, img.width(),img.height()=120,60, width(),height()=256,35
  ...

with the ... eliding many more similar LOG lines.  It does look like we're scaling in both dimensions, whether active or inactive right?  And that src_x offset is pretty unexpectedly big, I think big enough that even though we're in repeat mode, floating point coordinate precision will really start to break down.  The step between adjacent floats at that magnitude is ±128, and that src_x itself isn't even exactly representable.

~ $ cat test.c
#include <stdio.h>
#include <string.h>

int main(void) {
    float f = 1094795347;

    unsigned bits;
    memcpy(&bits, &f, 4);
    printf("%f %08x\n", f, bits);

    bits++;
    memcpy(&f, &bits, 4);
    printf("%f %08x\n", f, bits);

    return 0;
}
~ $ clang test.c
~ $ ./a.out
1094795392.000000 4e828281
1094795520.000000 4e828282

Adding in a quick hack like this did seem to get things drawing somewhat sensibly:

   auto src_x =  GetMirroredX() + background_offset_;
   if (src_x < 0) {
     src_x = 70;
   }

(This is all with the stripy ippei-gyoubu theme from Comment #0.)

I agree that source offset looks very, very wrong.

To me this suggests a possible uninitialized variable, likely |background_offset_|.