I suspect this is happening in Tab::UpdateForegroundColors(), specifically https://cs.chromium.org/chromium/src/chrome/browser/ui/views/tabs/tab.cc?rcl=133f5790775a57f71f1f889000c3e00b06497e6b&l=1017. It looks like the expected_opacity is high enough when hovering such that it passes TAB_ACTIVE to GetTabForegroundColor(). GetTabForegroundColor() then would use the wrong background color when computing the text color.

Potential fix: pass the actual background color to GetTabForegroundColor(), though this may not prevent the color switch on hover. Another idea: pass TAB_INACTIVE to GetTabForegroundColor() when hovering.

CCing pkasting@chromium.org since he probably has more context on this code.

This looks like "working as intended" to me.  We try to force the text color to be readable on hover.  The white text has a 2.67 contrast ratio against that background, the dark text 4.58.

I doubt this is because of picking the wrong foreground color, but without stepping through the code I'm not sure.

We have some code in browser_theme_pack.cc to force contrast too, but only where text colors are missing.  If the theme author forces a text color, we'll let them use it.  However, text color in the hovered state is not a directly-themeable color, so we don't have any way (currently) to do some equivalent "let the theme author force a color and don't change it" for that case.  When the theme author's default inactive tab text color choice has poor contrast, this sort of thing is the result :/

(We also can't just never change the color, because in many themes the effects of hovering are more pronounced.  We might be able to limit the number of cases where we call GetColorWithMinimumContrast() if we want to trade off accessibility for "less surprise".  You'd have to think carefully about it, and look at https://chromium-review.googlesource.com/c/chromium/src/+/1227215/5/chrome/browser/ui/views/tabs/tab.cc and the bug it was fixing.)

OK I'll remove the RBS for now. I still think the color change *might* be a bug though. In this case, GetTabForegroundColor thinks it's painting over a background color that is much different from the actual background color. This might be resulting in it picking black text instead of white. The contrast is still corrected by UpdateForegroundColors after the fact though.

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

commit dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c
Author: Collin Baker <collinbaker@chromium.org>
Date: Tue Dec 04 00:58:11 2018

Use true background color in GetTabForegroundColor

When an inactive tab is hovered over, GetTabForegroundColor uses either
the active or inactive tab background color rather than the blended
background color. This has GetTabForegroundColor take the true
background color as an argument to fix this.

Bug:  905066 
Change-Id: I5e91341ea0012e8c811c60d118a0ae4347716ed6
Reviewed-on: https://chromium-review.googlesource.com/c/1354230
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Collin Baker <collinbaker@chromium.org>
Cr-Commit-Position: refs/heads/master@{#613364}
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/new_tab_button.cc
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/tab.cc
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/tab_controller.h
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/dc8f22dd3cd1b4e6cb4bbc5cd3b362fb0d2b1f1c/chrome/browser/ui/views/tabs/tab_unittest.cc

The above commit is related to this: it doesn't prevent the color from changing, but it does prevent the contrast from being too low which could potentially happen with similar themes.

Otherwise, I'm going to consider this working as intended.