New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 21798 link

Starred by 100 users

Comments by non-members will not trigger notification emails to users who starred this issue.

New tab flashes white before showing theme background image

Project Member Reported by, Sep 14 2009

Issue description

Install a theme with a background image on the NTP. A large, dark-colored 
image will show the issue best. Open a new tab. See it flash white briefly 
before drawing the background image.

Only tested on Windows.
Showing comments 35 - 134 of 134 Older
 Issue 570533  has been merged into this issue.
Mergedinto: 470669
Status: Duplicate
Blocking: 470669
Status: Assigned (was: Duplicate)
Repro steps: 

1. On Linux, patch
2. ./out/Release/chrome 
3. Type chrome-search://local-ntp/local-ntp.html in the omnibox and enter


1. White flash before black
2. The following debug output:

[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "#ffffff"
[1:1:0429/141152:ERROR:WebViewImpl.cpp(4207)] Stop painting
[1:1:0429/141152:ERROR:WebViewImpl.cpp(4207)] Stop painting
[1:1:0429/141152:ERROR:WebViewImpl.cpp(4207)] Stop painting
[1:1:0429/141152:ERROR:ChromeClientImpl.cpp(940)] Start painting
[1:1:0429/141152:ERROR:ChromeClientImpl.cpp(940)] Start painting
[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "#000000"
[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "rgba(0, 0, 0, 0)"
[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "#ffffff"
[1:1:0429/141152:ERROR:ChromeClientImpl.cpp(940)] Start painting
[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "#000000"
[1:1:0429/141152:ERROR:ViewPainter.cpp(132)] Document background color: "#000000"

Labels: OS-Chrome OS-Linux OS-Mac

Comment 39 by, May 10 2016

Components: UI>Browser>NewTabPage
Labels: -bulkmove
Status: Duplicate (was: Assigned)

Comment 41 by, Jun 13 2016

Labels: zine-ntp-pe
Status: Assigned (was: Duplicate)
Not actually a duplicate - there's a general paint problem (the other bug), and a specific problem on the NTP (this one) where it loads the theme info asynchronously, so we end up showing a white screen first even if you have a dark theme.
Hi, any update on this bug?

I'm making (slow) progress on 470669. Gave an update there. I hope I can finish
it off soon-ish.

Comment 43 by, Jun 22 2016

Labels: Hotlist-Fixit-PE2016
Not yet. I hope to find some time to look into this after M53 branch point (June 30).
My eyes are in such pain.
Can someone make it flash BLACK, as a temporary solution?
At least until another solution is found. Thanks.
chrishtr, are you sure that there's a problem with the Local NTP code? From what I can tell, since it actually does all it can to get the correct background color immediately - it's specified via a css file. I guess it's possible that a paint happens before that css file is loaded, but then I don't see what the NTP could do about that?
(BTW, you can start Chrome with --force-local-ntp for easier testing!)
Assigning to myself for the moment to investigate comment 46.

Comment 48 by, Jul 21 2016

Labels: -size-medium Size-Medium is possibly related.  I have a (possible) partial fix in

Comment 49 by, Jul 29 2016

Labels: zine-triaged
As this is blocking  issue 470669  - I would like to refer to

Please fix this.  This is the last thing Chrome needs to start working well for night surfing.  The white flash is terrible and probably damaging to eyesight if using a dark theme.
Is there a css fix for this now?  If so, can someone give a walkthrough?
Can we get a status update?

Comment 55 by, Feb 19 2017

Hey, anyone still working on this?

Version 58.0.3017.0 (Official Build) canary (64-bit)
Version 56.0.2924.87

Comment 56 by, Feb 20 2017

Now that the paint bug ( issue 470669 ) has been fixed (at least partially?), it *should* be possible to do something about this on the NTP side. I'll try to look into it this week - no promises yet though ;)

Comment 57 by, Feb 20 2017

Status: Started (was: Assigned)
I've recently landed a change to load the theme background color as early as possible. (It was a server-side change, so it's already live.)

Now, reloading an already-open NTP does not flash white anymore, but opening a new one still does. (Maybe not all of the time, but at least "mostly" for me.)
I think this is all that the page itself can do here; the rest will have to happen deeper (i.e.  bug 470669 ).

Also notice that this will paint the theme's background color rather than white, so it'll only make a difference for themes that set a background color. In practice, it seems that many do not, even those with a dark background. One example of a theme that does set a background color:

Comment 59 Deleted

Great, thanks for your help. Close this bug then? I will be able to look again
at 470669 later today hopefully.
Blocking: -470669
Great to hear!

I'd prefer to leave this open until we have confirmed that things actually work :)
I'll swap around the "blocked on" relation though.
Blockedon: 470669
Thank you trieb!
What Chrome version has your fix? or, which Milestone is going to include it?
Also, how to quickly know which theme has background color set? This one makes right side of tabs and extensions hard to see..
Thanks a lot, you're truly awesome for moving this forward! We really really appreciate it.
@carmaged, it was a change serverside apparently, so it should just work without needing to do anything (besides ensuring you have a theme that specifies a background image/color.
I've re-tested on a current trunk build, and unfortunately the fix for  bug 470669  doesn't address this completely. Things seem to have improved a bit, but I get a white flash maybe one out of three times.

chrishtr@, any further ideas?
I just confirmed that the bug is in the renderer or your webpage.
Are you setting a black background on the inline body element?

Comment 68 by, Mar 10 2017

No, the background color comes from a css file referenced from the head element. However, I've verified that setting it inline in the body element also doesn't fix the problem. I'll send a test CL your way.
treib@, ever since the most recent Chrome update (stable channel) to v57.0.2987.98, the pages are flashing white again even within a tab that is already open.

Comment 70 by, Mar 16 2017

That's probably the regression mentioned in The fix for that is in M58, but unfortunately we figured it out too late for M57.
Update: chrishtr's in-progress should finally fix this issue. (Not landed yet, so no point in trying just yet!)
Project Member

Comment 73 by, May 3 2017

The following revision refers to this bug:

commit 94fdfaa5a34534601337ce1780eb8fe381f74c3b
Author: chrishtr <>
Date: Wed May 03 20:05:41 2017

Start out deferring commits in WebViewImpl.

This is a re-land of
The two bugs leading to revert of that patch seem to be either ok ( ),
or exhibit flashing even without the patch ( ).

BUG= 21798 

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


Project Member

Comment 74 by, May 3 2017

The following revision refers to this bug:

commit 94fdfaa5a34534601337ce1780eb8fe381f74c3b
Author: chrishtr <>
Date: Wed May 03 20:05:41 2017

Start out deferring commits in WebViewImpl.

This is a re-land of
The two bugs leading to revert of that patch seem to be either ok ( ),
or exhibit flashing even without the patch ( ).

BUG= 21798 

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


Status: Fixed (was: Started)
This is NOT fixed.

Chrome: 59.0.3071.29
Windows: Windows 10 Pro 10586.104

Video Proof:
I just fixed it one minute ago. Please try Chrome Canary tomorrow.
Do you know at what time the new bata version will drop?
It should end up in the Beta channel in early June, and the Stable channel
about 6 weeks later.
Status: Verified (was: Fixed)
Verified on ToT! Thanks chrishtr; this might deserve an award for fixing the longest-standing open bug :)

Info for everyone following along:
- The fix is in Chrome 60. You can check which version you have at chrome://version. As mentioned above, it should arrive in Beta in June, Stable in August.
- Note that this only works for themes that set a proper background *color* (even if they have a background image). In my experience, many dark themes don't do that. Here is one example that does it right:
If it doesn't work with your favorite theme, please contact the theme's author - there's nothing we (Chromium) can do about that!

Comment 82 by, May 4 2017

Labels: -Hotlist-Fixit-PE2016 M-60
I do not understand; To run the FIX; I need to install a theme that sets the background color?
Well, without a (dark) theme, there is no problem in the first place: The NTP is white anyway, so no visible flash. There was only ever a problem with *dark* themes. With the fix, the flash isn't white anymore, but instead in the theme's background color. So to make the flash go away, the theme has to set an appropriate background color, *in addition* to any background image it might have.

Comment 85 Deleted

... or Dark Reader:

Especially I'm curious how it will work with an extension like Dark Reader combined with using system default theme. Creating a new tab on stable version seems to first flash white, then dark grey (GTK theme toolbar/window background color) and then black (color set by Dark Reader).
> Well, without a (dark) theme, there is no problem in the first place: The NTP is white anyway, so no visible flash. There was only ever a problem with *dark* themes.

The incognito NTP has a dark background but still flashes white.
Status: Assigned (was: Verified)
According to, this is the tracking bug for the NTP white flash fix. This is not fixed in 60.0.3089.0 on the Mac.

Status: Started (was: Assigned)
Thanks for checking! Indeed, I can still reproduce the flashes on Mac. (Win and Linux are fine though.) I've reopened  bug 470669  for the remaining Mac problem, which probably isn't related to the NTP as such.

The incognito NTP seems to use the regular NTP's background color, so it still has flashes. I'll look into that.

Comment 91 by, May 4 2017

Re comment #81: In principle, if the theme doesn't set a background color, we could determine a "main" color for the theme's background image the first time it's loaded, and use that in future NTP loads.
Hello treib@:

On MacOS, there are two difference flashes in Incognito windows in latest Canary:

1.) When you open a new Incognito window, then it flashes white.

2.) When you open a NewTab in an Incognito window, then it flashes light grey.

Here is a screencast. Thanks in advance for fixing it.
5.1 MB Download
Is there any way to make it flash BLACK while a solution is found.

Comment 94 by, May 8 2017

Just showing black would fail the same way for light themes. It wouldn't be as eye-jarring, but it'd still be unattractive. 50% grey perhaps?
Per, Mac should be (at least mostly) fixed now.

I'll try to find some time to look into the incognito NTP soon.

Comment 96 by, May 10 2017

Also on Mac, Guest mode has a white NTP but shows a dark grey background when opening the window.
2.5 MB Download

Comment 97 by, May 18 2017

Labels: -Size-Medium Size-medium
Some notes on the incognito NTP:
We're getting a flash in the "default background color", which is specified by the theme if you have one installed, or white otherwise. So the themed case is fine (or as fine as it'll be any time soon, same as for the regular NTP), but the non-themed case is broken: Here the default background color should be the incognito NTP's dark gray rather than white.
This is *not* a problem in the incognito NTP's html/css; the flash happens before that. The following TODO in NTPResourceCache::CreateNewTabIncognitoCSS might or might not be related:
  // TODO(estade): this returns a subtly incorrect theme provider because
  // |profile_| is actually not the incognito profile. See 

Comment 98 by, May 19 2017

Labels: -Size-medium
More notes:
The color we see flashing before the incognito NTP is kDefaultColorNTPBackground from, returned by ThemeProperties::GetDefaultColor. That method already gets a "bool otr" ("off the record" == incognito) passed in, so it should be straightforward to provide a different value for incognito. Need to make sure not to break Guest mode, which is sometimes treated like incognito.
Project Member

Comment 100 by, May 19 2017

The following revision refers to this bug:

commit 6886191d1df3fc561df9010fc6c850d282a461de
Author: treib <>
Date: Fri May 19 17:20:50 2017

Fix white flash when opening incognito NTP

This specifies a different default background color when in incognito
mode in ThemeProvider::GetDefaultColor, matching the MD incognito NTP.
The previous (non-MD) incognito NTP uses an ever-so-slightly different
shade of gray, so that still has a barely-noticeable flash.

I've checked that this doesn't affect the regular or the guest mode
NTP, and that the incognito one works both with and without a theme.

BUG= 21798 

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


Could anyone share when the new stable release with fix included be released?
There's still a flash as of 60.0.3107.0 (c#99 landed in 3105). Should that cl have fixed this?
284 KB Download
The CL in #100 only fixed the flash in some cases. In many cases there are still theme providers which (incorrectly) provide the white background color.

I've uploaded, which doesn't fix the problem yet, but the CL description explains it.

MacOS Sierra Version 10.12.4
Chrome Version 60.0.3108.0 (Official Build) canary (64-bit)

Following extensions/theme installed:
- Dark Reader 3.4.3
- New Tab / Speed Dial 0.7.5
- Morpheon Black

The white flash appears sometimes after several seconds (more than 10) of inactivity (directly looking at chrome).

It is really sporadic and unpredictable but most noticeable with CMD + T. If there's anything I can do to help debug it I'm all ears (eyes are suffering for now).

Tried making a video but it is really unpredictable, when you least expect it: BAM!

Gentle ping.
Let me try to summarize the current state:

- Regular NTP (not incognito or guest):
Fine everywhere, both with and without custom themes. Exception: Custom themes that set a bad background color, in which case we can't do much.

- Guest NTP:
Fine (no theming support).

- Incognito NTP: Here's where it gets complicated.
On Windows: Fine, as far as I can tell.
On Mac: Still flashes, for reasons I don't understand. (They seem to be gray flashes rather than white though?!)
On Linux: Fine with "Classic" theme, but broken with "GTK+" theme, for the reason 2 mentioned in

shrike, does that match your experience?
msramek, any good ideas on how to solve Linux GTK+?
Anyone has any ideas where the remaining Mac flashes come from?
Correct on the Mac. The color is 0x4a, FWIW.

Out of curiosity: How did you find the 0x4a color?

FWIW, I couldn't find that color hardcoded anywhere in Chrome, though of course it's not easy to search for this. I did try hex and decimal.
Maybe it comes from the OS, somewhat similar to the GTK+ thing on Linux?

+estade: I think you're familiar with theming? See comment 106: On Mac, opening an incognito NTP flashes in 0x4a gray before showing the proper background color. Any ideas where that color might come from?
I dunno where that Mac color comes from. Some sort of default control color? Mac system theme?
> Out of curiosity: How did you find the 0x4a color?

I took a screengrab and used Photoshop to sample the color.

> I dunno where that Mac color comes from. Some sort of default control color? Mac system theme?

The incorrect color is coming from somewhere in Chrome, not macOS.

How has this not been fixed since 2009?  Is it really so difficult?
Data must be loaded in memory, if it takes too much time it must show a white page.
Sometimes it only flashes for a second, and sometimes it shows up a little longer, depending on how much weight the page.

Firefox had the same problem but it was possible to fix it by changing color from white to black or gray.
The only way to fix it in chrome is to change the white color.

Even google apps on android have the same problem because they are badly designed.
Gmail, Chrome, Play after starting it first show white page, for comparison install apps like NYTimes or TV Routers.

It's funny how long it takes to fix it.

Update on #106 re incognito NTP:
The flashes are not only for the Linux GTK+ theme, but for any theme which sets an NTP background color, but no background image. The reason is in NTPResourceCache::CreateNewTabIncognitoCSS: It uses the theme background color only if there's a background image; otherwise it falls back to the default color.

I see two ways to get rid of these flashes:
1. Duplicate this logic somewhere in ThemeService, so it uses the same background color as NTPResourceCache. (Ugly, but keeps the current behavior.)
2. Change the incognito NTP to use the theme background color, even when there is no background image. (Feels less hacky, but will change the incognito NTP.)
Labels: -M-60
CL that fixes the Incognito NTP flashes with themes, i.e. option 1. above:

I also found the culprit for the Mac flashes: updateBackgroundColorFromWindowTheme in contains a very similar hack as the CL above, but it hardcodes the color to 0x32 (which was the Incognito NTP background before the MD version). Unfortunately, fixing that to use the correct color 0x30 doesn't quite fix the flashes. My guess is that the color we set there gets reinterpreted into a different color space, or gamma "corrected", or something along those lines.
(Just to be clear: I have verified that this place is indeed the culprit - e.g. hardcoding the background color to red there makes the flashes red.)
Turns out the flashes on Mac affect not only the Incognito NTP, but also the regular NTP with themes that have a background color. Example:

The culprit seems to be that TabContentsController::updateBackgroundColorFromWindowTheme uses skia::CGColorCreateFromSkColor to convert the background color from SkColor to CGColor, which uses the "Generic RGB" color space. I don't know what exactly "Generic RGB" is and the documentation [1,2] isn't particularly helpful, but apparently it's *not* the same as SRGB, since using SRGB seems to fix the problem.

Re #116, the difference between GenericRGB and sRGB is pretty small -- the issue we're seeing in this bug is that we have flashes of white when the color should be black.

That said, I've been trying to kill off our use of GenericRGB and DeviceRGB over in  issue 254361 .
The issue I'm fixing with is not white flashes (those should all be addressed after, but flashes of slightly-off colors (e.g. slightly-too-bright gray for the incognito NTP). So that's consistent with the color space difference.

Out of curiosity, what exactly *is* GenericRGB? The official documentation is annoyingly unspecific...
Project Member

Comment 119 by, Jan 10 2018

The following revision refers to this bug:

commit b50ed35f31c3f2112fcd984151c2f866f577d20e
Author: Marc Treib <>
Date: Wed Jan 10 11:57:18 2018

Incognito NTP: Avoid flashes with themes with a background color

The Incognito NTP uses the theme's background color only if the theme
also has a background image, otherwise it falls back to the default
background color (which is rgb(32,32,32)). This caused flashes when an
Incognito NTP is opened with a theme that has a background color but no
background image: first the theme's background color was drawn, then as
soon as the page loaded, it went back to rgb(32,32,32).
This CL fixes the flashes by moving the special background color logic
to ThemeService::GetColor.

Bug:  21798 ,  719236 
Change-Id: I0c5553ceef95b71a8e0b90e44bd86da83d2b875a
Commit-Queue: Marc Treib <>
Reviewed-by: Evan Stade <>
Cr-Commit-Position: refs/heads/master@{#528284}

Labels: Needs-Feedback
Tested this issue on Mac OS 10.12.6, Ubuntu 14.04 and Windows-10 using chrome latest canary #65.0.3318.0 by following the steps mentioned below.

1. Installed dark theme from chrome webstore
2. Opened multiple Incognito NTP and Windows 
3. Observed no white flashes 

Able to reproduce this issue on chrome latest stable #63.0.3239.132, but not on latest canary.

treib@ Attaching screen cast for reference, could you please confirm the above steps is the right way to verify the fix for this issue from chrome-TE end? Please let us know if any steps is missing.


687 KB View Download
Thanks! Yes, that looks correct.

Now only the Mac Incognito NTP *without* a theme still flashes. That will be addressed by and
Labels: -Needs-Feedback
Version 65.0.3319.0 (Official Build) canary (64-bit)
I now have this behavior on Windows 10:
1. Windows standart (not dark mode) theme
2. Start Chrome, with Material Incognito Dark Theme (
(I check with Morpheon Black - same)
3. Create new tabs - no flash
4. Switch Windows to High contract black theme
5. Create new tabs - no flashes
6. Exit from Chrome
7. Start Chrome again
8. Create new tabs - FLASHES
9. Switch Windows to standart theme
10. Create new tabs - FLASHES
11. Exit from Chrome
12. Start Chrome again
5. Create new tabs - no flashes

So, now it's depend on theme settings when Chrome starting.
Re 123: Thanks for reporting! Indeed, there are flashes if you enable one of Windows' "High contrast" themes (#1, #2, and Black all have this problem). This does not even require any Chrome theme. Simplified repro:
1. Enable Windows "High Contrast Black" (or #1 or #2) mode.
2. Restart Chrome.
3. Open NTP, observe black flash.

There's a separate issue in that some of the "high contrast" changes only apply after a Chrome restart - step 2 above shouldn't be necessary. Here, let's focus on getting rid of the flashes after restarting Chrome.
Project Member

Comment 125 by, Jan 16 2018

The following revision refers to this bug:

commit b24da2a239e0587a01b769c3e5a18ddefd07d1b7
Author: Marc Treib <>
Date: Tue Jan 16 09:44:26 2018

[Mac] Use SRGB color space when converting from SkColor to CGColor

This fixes flashes when opening themed or incognito NTPs:
TabContentsController::updateBackgroundColorFromWindowTheme uses
skia::CGColorCreateFromSkColor to convert the background color from
SkColor to CGColor, which used the "Generic RGB" color space before.
This does not match SRGB, which is what the NTP (or any WebContents)
uses, as far as I can tell.
This CL fixes the discrepancy by making CGColorCreateFromSkColor use

Bug:  21798 ,  254361 ,  719236 
Change-Id: I14b03690f585d266b6329d6b19b37ee8ac36c6ce
Reviewed-by: Justin Novosad <>
Reviewed-by: ccameron <>
Commit-Queue: Marc Treib <>
Cr-Commit-Position: refs/heads/master@{#529390}

Okay, turns out there are more things wrong with the NTP and inverted color schemes. I've filed  bug 802186  for that.
Labels: TE-Verified-M65 TE-Verified-65.0.3318.0
As per comment #121 adding verified label for this issue.

Project Member

Comment 128 by, Jan 18 2018

The following revision refers to this bug:

commit 2ac43b4263e42111acbcf607f88579a93fe2817a
Author: Marc Treib <>
Date: Thu Jan 18 06:42:08 2018

[Mac] Remove special hack for incognito NTP background color

It's not required anymore after (It had also
diverged from the correct color in the meantime...)

Bug:  21798 ,  719236 
Change-Id: If98185ffe59865dcf7fb52b8d5a3ed534db60aed
Commit-Queue: Yuri Wiitala <>
Reviewed-by: ccameron <>
Reviewed-by: Yuri Wiitala <>
Cr-Commit-Position: refs/heads/master@{#530077}

Status: Fixed (was: Started)
That should do it - now the Mac incognito NTP doesn't flash anymore either! Hurray!

Still broken are inverted color schemes, such as Windows' "High Contrast" themes, see comments #123/#124. Those problems are tracked in  bug 802186 .

Comment 130 by, Jan 18 2018

Does this address the black flash when opening a new tab in guest mode?
Screen Shot 2018-01-18 at 11.55.23.png
26.6 KB View Download
Yup, turns out I accidentally fixed that too with the CL in #128 above :)

(Note that the fix isn't even in Canary yet; it should be there tomorrow.)
Verified the fix on Mac 10.12.6, Win-10 and Ubuntu 14.04 using latest Chrome  version #65.0.3325.0 as per the comment# 131
Attaching screencast for reference.
Observed that "No flash is seen before showing theme background image"
Hence, the fix is working as expected.
Adding the verified labels.

2.4 MB View Download
Labels: TE-Verified-65.0.3325.0
That's great progress.  For those ways of getting to the new tab, it's fixed. 
 However, the issue still occurs if you open a page using middle click (or right click -> open link in new tab), then close the current tab.
Showing comments 35 - 134 of 134 Older

Sign in to add a comment