Update: I closed a tab and the bug has now disappeared (can't reproduce).

Closest thing I'm aware of is bug 869933, but that wouldn't make the tab text invisible.  That sounds like the whole tab is being marked as non-visible.  Was this happening to every non-active tab every time you rolled over it?

Yes. I was literally waving my cursor over the tab strip and watching everything I pointed at disappear while the cursor was over it (except for the currently active tab, which would not disappear).

I haven't been able to reproduce this since it got "fixed" yesterday. It's not reproducing now. I can't recall any special circumstances yesterday except that I was logged into a second profile in Chrome OS. (Switching between the two profiles did not fix the issue, but the issue did not manifest in the second profile, only the primary profile.)

Sorry I didn't mean to make this Restrict-View-Google. I only filed it from my google.com account because I didn't have my 2FA for chromium. I can't find any way to remove the RVG label.

@4: Adding the "allpublic" label cancels out that auto-applied restriction.

It seems like the combination of "whole tab disappears, not just the background image" and "only happens on hovering an inactive tab" ought to be enough to track this down, but I'm struggling to do so.

Some more thoughts after talking to kylixrd:
* He's seen this before as well, and couldn't reproduce at will either.
* He saw it with non-themed windows, so the themed-ness is probably not relevant.
* His experience is that hovering the tab makes it vanish instantaneously, not just fade out, so this isn't some kind of bug where the animation fades the wrong way or something.
* Because you saw it with themed windows, this isn't something with the tab background cache (which is disabled when tabs have a background image).  But that's kind of clear anyway from the fact that the tab label disappears, and not just the background.
* It looks like the screenshot in comment 0 is in touch mode based on the tab height, and in touch mode, TabStrip::ShouldPaintTab() can set a clip for the tab.  If GM2TabStyle::GetPath() has some sort of bug in this case that returns a zero-width or offset-outside-the-tab-bounds clip rect, maybe that could account for this?  Note that both the interior and exterior paths would need to be broken, I think, because the tab children (e.g. the title) would be drawn during Tab::PaintChildren(), which doesn't use the same clip as Tab::OnPaint().
* Allen thinks he saw this on canary around two weeks ago, which was around the time Dana's style/path refactors landed.  Not sure what the precise time ordering here is.

So one hypothesis is that maybe something in Dana's refactor made it so we can have a bad clip path in this case.  But I'm not sure why hovering the tab would make any difference if that's the cause.

The interior path calculation calls GetSeparatorOpacities(), which in turn references the hover value.  If somehow the tab hover value went outside the 0..1 range that could have some bizarre effects.  But I don't think that can happen.

Maybe a productive investigation route would be to try to intentionally introduce bugs in different places relating to painting, the path calculations, the separator opacities, the hover controller, etc. to see if we can cause a similar effect to happen.  Then we could try and determine how that bug might arise in the existing code.

I'm sending this to Dana to triage, not only because of her work on refactoring this, but because her team will be taking over tabstrip ownership in the long run.  Happy to keep consulting, though.

It is definitely possible this was a side-effect of the tab rendering refactor. It would be really nice if this were something like reproducible, though.

I'll look into possibilities. Might just require turning on touch UI via a flag and mucking with Chrome until it breaks.

Maybe there's an uninitialized variable somewhere.  I wonder if some sanitizer could help us find this.

I can certainly take a second look at the code, but there's just not a lot of data there to be uninitialized.

> It looks like the screenshot in comment 0 is in touch mode based on the tab
> height, and in touch mode, TabStrip::ShouldPaintTab() can set a clip for the
> tab.

I don't think it's in touch mode. It is a touch laptop (Asus Flip) but I'm pretty sure it was in keyboard+mouse mode. I think it just looks like touch mode because it's a high-resolution display.

> Allen thinks he saw this on canary around two weeks ago, which was around the
> time Dana's style/path refactors landed.  Not sure what the precise time
> ordering here is.

Note that I saw this on stable (69).

@9: I suggested it was touch mode because the tab height is 41 DIP, which is Touchable Refresh :).  Normal is 34.

Good pointing out the version number (I don't know why I wasn't paying attention to that).  Definitely rules out the refactoring.

Can we verify if this is happening at all in 70/71 and if there's any even remotely reliable way to reproduce?

If not I feel like I'm going to be going hunting for a thing that might not even be there anymore, with all of the refactoring that has happened.

I have never seen it again.

However, I do frequently see an issue where my tab text is black (in my theme it's supposed to be white) until I mouse over it, then it goes white. Could be the same issue, but I can file a separate bug if desired.

Comment 13 sounds like  bug 903438  (which has been fixed).

OK let's just close this out. (Can't reproduce)