ah, the age old problem of rendering subpixel text on a non-opaque bg. Do we have a bisect range?

shouldn't we make them opaque?

For various reasons, we need to render the text itself on something that might not be opaque at the time, but the background behind it is supposed to always be opaque.  In this case, it looks like we're not upholding the second half of that guarantee.

Bisect result :
Good build : 67.0.3376.0/10523.0.0 - Peppy
BAD  build : 67.0.3381.0/10525.0.0 - Peppy

There is no diff. chrome build between cros 10525.0.0 & 10523.0.0 build.
Unable to reproduce the issue on 68.0.3432.3 - Ubuntu 14.04

I guess this absolves Dana's patch since it landed after 67 and wasn't merged.

This last cropped up as  bug 819865 . Can you check against cros 68 instead of Linux 68?

Able to reproduce the issue on 68.0.3437.0/10704.0.0 - Candy
>>  Can you check against cros 68 instead of Linux 68?

Marked as "RBS" since it is a regression from the M66 and user has hard time to read the tabs.

Evan, is there a way you can take this on?  I'm absolutely flooded with time-critical material refresh stuff right now.

I can try to look at it soon but it's not going to happen before 67 gets to stable. Perhaps it should be left available for the time being. If anyone has cycles before I mark the bug started, please swoop it.

related: inactive frame images are missing. See attached.

Both the original issue reported here and the inactive frame images are fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1080277

Deleted: FP4rruF27q3.png 706 KB

	FP4rruF27q3.png 706 KB View Download

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

commit 330fc0661f88a200ab9e2d58cb5812dc56c57602
Author: Evan Stade <estade@chromium.org>
Date: Fri Jun 01 00:27:35 2018

Themes - when a theme image is missing, fall back to normal
frame background image.

Currently, only inactive incognito frame images have this fallback.
Now the fallback applies to inactive normal frames as well as active
incognito frames.

There's a comment in tab_strip.cc which indicates the tab
strip code expects this to be the case:

  [...]the theme provider will create the incognito frame image
       from the normal frame image [...]

This restores behavior that was present before 8e23c7996d890fdc77fc

Bug:  845976 
Change-Id: Iee6487373c8651ef76a1899ae5d68c5884e9d597
Reviewed-on: https://chromium-review.googlesource.com/1080277
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563458}
[modify] https://crrev.com/330fc0661f88a200ab9e2d58cb5812dc56c57602/chrome/browser/themes/browser_theme_pack.cc
[modify] https://crrev.com/330fc0661f88a200ab9e2d58cb5812dc56c57602/chrome/browser/themes/browser_theme_pack_unittest.cc

Your change meets the bar and is auto-approved for M68. Please go ahead and merge the CL to branch 3440 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit c5999442f7ade96516d1070dbfde4f5319d89883
Author: Evan Stade <estade@chromium.org>
Date: Mon Jun 04 18:44:21 2018

Themes - when a theme image is missing, fall back to normal
frame background image.

Currently, only inactive incognito frame images have this fallback.
Now the fallback applies to inactive normal frames as well as active
incognito frames.

There's a comment in tab_strip.cc which indicates the tab
strip code expects this to be the case:

  [...]the theme provider will create the incognito frame image
       from the normal frame image [...]

This restores behavior that was present before 8e23c7996d890fdc77fc

Bug:  845976 
Change-Id: Iee6487373c8651ef76a1899ae5d68c5884e9d597
Reviewed-on: https://chromium-review.googlesource.com/1080277
Commit-Queue: Evan Stade <estade@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#563458}(cherry picked from commit 330fc0661f88a200ab9e2d58cb5812dc56c57602)
Reviewed-on: https://chromium-review.googlesource.com/1085499
Reviewed-by: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/branch-heads/3440@{#150}
Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733}
[modify] https://crrev.com/c5999442f7ade96516d1070dbfde4f5319d89883/chrome/browser/themes/browser_theme_pack.cc
[modify] https://crrev.com/c5999442f7ade96516d1070dbfde4f5319d89883/chrome/browser/themes/browser_theme_pack_unittest.cc

Verified the fix in Chrome 68.0.3440.15/CrOS 10718.13.0 - Peppy, Paine, Enguarde

This bug wasn't on my radar as a RBS since it's tagged as fixed and isn't requesting a merge  for M67.  

M67 already pushed at 1% stable for non-ARC++ boards.  This appears to be cosmetic only and doesn't satisfy RBS requirements.  Removing the label.  Please re-apply with context if otherwise, and tag merge requests for M67 and M68.  Thanks

I think we should take this in 67 (already merged to 68), but I don't think we should respin just for this --I would merge to the branch so if we do any other respins we'll pick this up.

The problem is not cosmetic but usability -- background tab titles become difficult-to-impossible to read (depends on the title and the theme).

The main reason not to take this would be that it only affects certain themes, so the number of users impacted is limited.  But for those users, the impact is pretty large.

I am OK with either decision; just trying to provide more context.

For Chrome OS:  RBS shouldn't be used for a merge request; it should only be used if we need to halt the current push and block future.  If you'd simply like to merge a priority bug please restrict to the merge request labels.

Apologies to govind@ who should have directed this since it's multiplatform.  But it escalated on the CrOS side this AM and I needed to mitigate.  imho we should remove the RBS since this isn't a blocker per #23.

I thought about actually making it a blocker, but I'm not sure I can justify that given that it only affects a percentage of users.  So I'll remove RBS and leave the merge request tag.

For Desktop M67 has been out since 05/29 and there is no plan for M67 respin at the moment unless critical issue arise.

#23 & #25, this is not truly M67 stable blocker. Hence, rejecting merge to M67. Pls do let me know if there is any concern here. Thank you.