Triage: Assigning to bsep@ who was looking at invalidation issues in this area a few weeks back.

Not Mac-specific; kylixrd and I noticed this on Windows today.

Seems to be some kind of regression.

I was getting this to reproduce more frequently locally when hovering an inactive tab until it was animated to the full-hovered state, then quickly moving my mouse diagonally down out the strip so I brushed over an adjacent tab just before leaving.

OK, I see the issue.  To repro at will, move your mouse carefully down into the extensions where the tabs overlap while hovering a background tab.

TabStrip::PaintChildren() checks IsMouseHovered() on tabs as a way of asking "is this the hovered tab".  That's not quite correct as-is because View::IsMouseHovered() is basically just "does this screen coordinate fall within this view's hit test region".  So when you mouse over the region where tabs overlap, both the tabs return true for this test.  Since we only track one |hovered_tab| and repaint it later, the other such tab won't get painted correctly.

Either Tab needs to override IsMouseHovered() (or modify GetHitTestMask()) so that it doesn't report that it's hittable in areas where it should be overdrawn by another tab, or else this code needs more sophisticated detection/tracking of the hovered tab(s).

This is Allen's code, assigning to him.

Maybe we can just ask the tab if the hover controller animation IsShowing()?  That should correspond with "tab is currently hovered".  Or maybe the TabStrip actually knows the hovered tab already, but I kinda doubt it (didn't look).

Cool. We've seen this behavior, but weren't sure how to repro. This shouldn't be too difficult to fix.

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

commit 0cc4260d031d608a3bd19ef4b6d8e527e2a25237
Author: Allen Bauer <kylixrd@chromium.org>
Date: Mon Jun 11 22:19:44 2018

Fixed case where a tab would not be painted when hovering in the overlap of two tabs.

Due to the tabs overlapping, more than one tab can return that the mouse is hovered over its bounds. This would cause |hovered_tab| to be overwritten and the previously hovered tab to not get painted. This change ensures that only one tab is ever considered "hovered". For two adjacent tabs that are hovered, the one on the left is favored.

The reason for all of this code in the first place is to ensure that the currently hovered background tab is always painted right before the active tab. This visually manifests as the hovered tab always painting "above" the adjacent tabs. The |last_hovered_tab_| field also ensures that when no tab is hovered anymore, the last hovered tab continues to be painted in the right order while the hover animation is still running.

Bug:  846429 
Change-Id: I95723ba79f683a31f45a117bd0833a143073a46a
Reviewed-on: https://chromium-review.googlesource.com/1093734
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Allen Bauer <kylixrd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566170}
[modify] https://crrev.com/0cc4260d031d608a3bd19ef4b6d8e527e2a25237/chrome/browser/ui/views/tabs/tab_strip.cc