For purely visual bugs such as this one, posting screenshots is more helpful than videos.

Not a priority in M-50 or M-51 since MD is not enabled by default on Windows. And since I don't think Linux has the concept of a "guest mode" (correct me if I am wrong on that) it looks like this is a Win-only issue. Handing over to Peter.

I can't reproduce this on my Win trunk build, which is M-51.

Can you retest on trunk/canary?  If this doesn't reproduce there, we can close this, as we aren't worried about Windows MD bugs in M-50.

yes, linux has guest mode. I'm pretty sure this bug is invalid. Everything looks good to me on tip of tree. Perhaps the reporter is noticing the fix to  bug 577376 

With response to comment #3 :
Rechecked above issue on ToT build 384192 and issue is still reproducible. Please refer the attached screenshot.

Deleted: guest_tab_title.jpg 153 KB

	guest_tab_title.jpg 153 KB View Download

Hmmmmm.

The behavior in the video looked to me like the tabstrip was incorrectly caching the appearance of an incognito background tab as the guest mode background tab.  That's why on mouseover the tab's appearance changed so dramatically; that causes us to draw the tab anew instead of using the cached appearance.

Ultimately, the tabstrip determines "incognito" state as follows:

bool BrowserTabStripController::IsIncognito() {
  return browser_->profile()->IsOffTheRecord();
}

I assume that this code is incorrect: that it returns true for both incognito and guest windows, but in fact that ThemeProvider::GetColor(ThemeProperties::COLOR_BACKGROUND_TAB) will return different values for those.  That's certainly what the CL in the regression range indicates.

In any case, it seems like the likely fix is to change the implementation of BrowserTabStripController::IsIncognito() to this:

  return browser_->profile()->GetProfileType() == Profile::INCOGNITO_PROFILE;

I don't know why neither Evan nor I can reproduce this, but it's probably fastest and easiest for me to try landing this change, and then have the reporter retest the same environment/steps (in both a bad and good build, to ensure the bug hasn't mysteriously disappeared, and that this change fixes it).  If that works, then this should be merged to M-50, as it can in theory affect all views TabStrips, not just Windows, even if we're not sure precisely how to repro.

OK, an attempted fix is in the queue: https://codereview.chromium.org/1845813002/

yfulgaonkar, once this fix lands (a bot should update this bug):

* Re-verify you can reproduce this consistently with a build just before the change goes in
* Test whether a build after the change goes in has fixed the problem
* In either case, assign back to me when done so I can either merge to M-50 or consider further what to do.

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

commit 3044c21c2c8dadd5531258238b8befe6e1ff21fb
Author: pkasting <pkasting@chromium.org>
Date: Thu Mar 31 07:28:35 2016

Suspected fix for a tab image caching bug.

If we cache the same image for guest and incognito tabs, but they use different
themes, we'll have drawing glitches.

I can't reproduce the original problem, so I'm going to try landing this and see
if the reporter sees things clear up.

BUG= 599077 
TEST=See bug
TBR=estade

Review URL: https://codereview.chromium.org/1845813002

Cr-Commit-Position: refs/heads/master@{#384210}

[modify] https://crrev.com/3044c21c2c8dadd5531258238b8befe6e1ff21fb/chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc
[modify] https://crrev.com/3044c21c2c8dadd5531258238b8befe6e1ff21fb/chrome/browser/ui/views/tabs/tab_controller.h
[modify] https://crrev.com/3044c21c2c8dadd5531258238b8befe6e1ff21fb/chrome/browser/ui/views/tabs/tab_strip_controller.h

With response to comment #8 :
Rechecked above issue on ToT build 384213, it seems to be fixed and working as intended.

pkasting@ can we close this out if this is verified?

If this is fixed, then I think we need to merge the fix to 50.

Chrome OS has a different notion of "guest mode" than Win/Linux. You have to enter into it from the login screen, and you cannot open incognito windows (since the whole session is already being treated as if you were in incognito).  Issue 577376  set the correct theming for CrOS guest mode, and I just verified that it still looks correct on CrOS M-50 beta.

Since MD is not enabled by default on Windows or Linux in M-50, I do not think a merge is necessary here.

Peter, feel free to change back the labels if you disagree or if I am misunderstanding something here.