**UI mass triage**
Somehow we are unable to reproduce the issue on Mac using latest stable-70.0.3538.110 & canary-	72.0.3621.0 as per C#0 steps.New (active) tab is highlighted  instead of inactive tab.Adding respective labels to proceed further.

I have verified that this reproduces on Windows.

(To clarify, reproduces on Windows on version 70. I have not been able to reproduce on trunk yet but will try.)

It requires a LOT of tabs - not just enough tabs to go off the screen.

Also anything that causes the tabstrip to repaint (hovering over a tab or resizing the window) results in the highlighting going away.

I have verified that the effect happens when the tabs are all minimum width and the width of the additional tabs that are hidden (because there is no room to render them) puts the new tab past where the edge of the browser window would be. This is backed up by the number of tabs required to create the effect being dependent on the width of the browser window.

'm guessing that this is a case of some sort of invalidate call having no effect because it's outside the window bound. A fix for this is probably fairly straightforward; we just need to force the previously active tab to repaint when a new tab is added (or perhaps better, when it loses focus).

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

commit d80f1a220d9c95ab45afb8fdc44a2b926893132a
Author: Dana Fried <dfried@chromium.org>
Date: Mon Dec 03 21:26:30 2018

Fix layout/repaint of tab on focus or alert change.

Also removes code associated with "show close button on hover" in
non-touch situations because showing of close button on inactive tabs is
now purely a function of tab size and the code had no effect.

Previously, tabs were relying on invalidation of the tabstrip to repaint
when active status changed. This resulted in cases where when the number
of tabs at minimum size exceded the size of the browser window, pinned
tabs would not repaint when a new tab was added, resulting in them
appearing to still be active (until something else invalidated the
tabstrip, like a mouse event or resize).

Now we're using InvalidateLayout() and SchedulePaint() correctly to make
sure things which could change the render or layout state of a tab
result in the tab being laid out and/or repainted.

Bug:  896849 
Change-Id: If2fcdafe80a0d22dc1d7c5c2c4a703729b8ed55b
Reviewed-on: https://chromium-review.googlesource.com/c/1357329
Commit-Queue: Dana Fried <dfried@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613252}
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab.cc
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab_controller.h
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab_strip_unittest.cc
[modify] https://crrev.com/d80f1a220d9c95ab45afb8fdc44a2b926893132a/chrome/browser/ui/views/tabs/tab_unittest.cc

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

commit 0bfabec2ac11decb989a7a03ea5980eaf56893e6
Author: Peter Boström <pbos@chromium.org>
Date: Tue Dec 04 16:11:04 2018

Revert "Fix layout/repaint of tab on focus or alert change."

This reverts commit d80f1a220d9c95ab45afb8fdc44a2b926893132a.

Reason for revert: Tab icons are no longer reliably laid out.

Bug:  chromium:911508 

Original change's description:
> Fix layout/repaint of tab on focus or alert change.
> 
> Also removes code associated with "show close button on hover" in
> non-touch situations because showing of close button on inactive tabs is
> now purely a function of tab size and the code had no effect.
> 
> Previously, tabs were relying on invalidation of the tabstrip to repaint
> when active status changed. This resulted in cases where when the number
> of tabs at minimum size exceded the size of the browser window, pinned
> tabs would not repaint when a new tab was added, resulting in them
> appearing to still be active (until something else invalidated the
> tabstrip, like a mouse event or resize).
> 
> Now we're using InvalidateLayout() and SchedulePaint() correctly to make
> sure things which could change the render or layout state of a tab
> result in the tab being laid out and/or repainted.
> 
> Bug:  896849 
> Change-Id: If2fcdafe80a0d22dc1d7c5c2c4a703729b8ed55b
> Reviewed-on: https://chromium-review.googlesource.com/c/1357329
> Commit-Queue: Dana Fried <dfried@chromium.org>
> Reviewed-by: Peter Boström <pbos@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#613252}

TBR=pbos@chromium.org,dfried@chromium.org

Change-Id: Ic7f3900d75aab0eda985368785b9182835b15d35
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  896849 
Reviewed-on: https://chromium-review.googlesource.com/c/1361301
Reviewed-by: Peter Boström <pbos@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613567}
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab.cc
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab_controller.h
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab_strip_unittest.cc
[modify] https://crrev.com/0bfabec2ac11decb989a7a03ea5980eaf56893e6/chrome/browser/ui/views/tabs/tab_unittest.cc

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

commit 1106cb0210424ce58ea113e6f2bb660a859a9487
Author: Dana Fried <dfried@chromium.org>
Date: Tue Dec 04 21:22:55 2018

Fix fail to repaint tab on active change.

Any change in tab highlighting now results in repaint.

Bug:  896849 
Change-Id: I0b5e100140e99d2730f60b8efb5a416ca1dda4b7
Reviewed-on: https://chromium-review.googlesource.com/c/1361666
Reviewed-by: Peter Boström <pbos@chromium.org>
Commit-Queue: Dana Fried <dfried@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613699}
[modify] https://crrev.com/1106cb0210424ce58ea113e6f2bb660a859a9487/chrome/browser/ui/views/tabs/tab.cc