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

Issue 126341 link

Starred by 56 users

Issue metadata

Status: Duplicate
Merged: issue 21798
Closed: Oct 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Opening a new tab flashes a white page instead of the "most visited" background.

Reported by, May 5 2012

Issue description

Chrome Version       : 18.0.1025.162
OS Version: 6.0 (Windows Vista, Windows Server 2008)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 4.x:
IE 7/8/9:

What steps will reproduce the problem?
1. Open a new tab

What is the expected result?
Tab "page area" is not bright white, but instead a render of the "Most Visited" page.

What happens instead?
Tab is bright white.

Please provide any additional information below. Attach a screenshot if

This is kind of a "quality of life" improvement. When it's dark and I'm reading dark web pages and I open a new tab I get a flash of bright blinding light. Would be nice to be able to either set that default background page color to black, or to just have it render the "Most Visited" screen before displaying anything.

UserAgentString: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

I absolutely agree, and was thinking of reporting this same issue:

I'll vote for a black background that is displayed initially, until the target webpage loads -- whenever a different Chrome tab is first displayed -- including, every time Alt-Tab is used to jump between tabs.

Please, no more blinding flashes of bright, white light -- especially at night!

Labels: -Area-Undefined Area-UI Feature-NewTabPage

Comment 3 by, May 5 2012

#0, 1: Why can't you just install a dark theme?

Comment 4 by, May 6 2012

My theme IS dark. Try the repro steps. Doesn't matter what theme you have installed, it always flashes a completely white page before rendering the "most visited" page.
Labels: -OS-Windows OS-All
Status: Available
yea, this should be feasible, as we do have an ntp theme background color. I'm not sure how easy it would be because it may be difficult to determine what URL will be shown when we are creating the webview.
I totally agree. Any solutions?

Comment 7 by Deleted ...@, Nov 6 2012

I agree, please provide a solution to the blinding white light.
Project Member

Comment 8 by, Mar 10 2013

Labels: -Area-UI -Feature-NewTabPage Cr-UI-Browser-NewTabPage Cr-UI

Comment 9 by Deleted ...@, Apr 1 2013

yea, this needs to be fixed. Super annoying.

Comment 10 by Deleted ...@, Apr 12 2013

Thought I was the only one! This cannot be that hard google, white or black, just give us the option damnit!!!

Comment 11 by, Apr 23 2013

 Issue 230406  has been merged into this issue.

Comment 12 by, Apr 23 2013

is this a dupe of  issue 1373 ?
Its not completely a duplicate, as Chrome will show a pure white page when first launching too. 
Not a duplicate-- 1373 has not fixed flashes for new tabs.
this is currently the same with the new cache-able NTP...

Comment 16 by Deleted ...@, Jul 25 2014

Very annoying when someone use "High Contrast" theme on Windows and "Midnigh Surfing" theme in Stylish extension :/

Comment 17 by Deleted ...@, Jul 25 2014

I would increase priority of this issue.
I agree with this, its been an issue for a long time now.

Comment 19 by, Jul 25 2014

Thanks for your feedback, will leave this at Pri-2, but will try to take a look soon.

Comment 20 by, Jul 25 2014

Thanks for the update mathp. As someone who normally uses very dark themes and css the bright white flash is quite annoying. I'm glad this is getting looked into
Has anyone taken a look at this lately? Mathp?
It looks like the flashing white page from  Issue 1373  is not quite fixed either and does provide a bit of a worse experience.

It looks like we may be able to just try to set the background to `ntp_background` on load, but I'm not sure if the engine actually supports that.

This is still on the list of things we have to look at though and I'll keep you all in the loop.
I want to fix this bug.

Comment 24 by, Oct 22 2014

The code to fix is located in src/content/browser/renderer_host/ for the Mac OS X version of Chromium. Changing kCGColorWhite to kCGColorBlack there helps a lot :-)
Compare my comment for  Issue 64317  which seems to be a duplicate
Owner: ----
Ah thanks for the tip!  I've been too busy to investigate this, and shouldn't hog the bug. Please take over if you'd like to work on this!
Ah thanks for the tip!  I've been too busy to investigate this, and shouldn't hog the bug. Please take over if you'd like to work on this!

Comment 27 by, Oct 25 2014

Changing the SetColor() statements in RenderWidgetHostViewAura::InitAsChild(), RenderWidgetHostViewAura::InitAsPopup(), and RenderWidgetHostViewAura::InitAsFullscreen() in the source file content/browser/renderer_host/ fixed most of the flashing under Linux for me.

I have to stop working on this issue now, since I already spent too much time tracking these two source code locations and have to continue other work. I'm sorry for not being able to take over for proper fixing since for my embedded case where the white flashes were an issue, a code change is currently sufficient.
Status: Assigned
Thanks for your contribution! We do plan on fixing it.

Re-assigning to Sam so it doesn't get lost, feel free to re-assign to someone else.
Please get on top of this Google.  You should be embarrassed about this.  I shouldn't have to close my eyes every time I click a link or change tabs.

Comment 30 by, Feb 24 2015

This bug made me switch to Firefox. Should be priority 1!
 Issue 457714  has been merged into this issue.
Started working on the Mac incarnations of this in  issue 470669 . With the various CALayers' colors set correctly, we still get a white frame from the compositor (so, presumably from Blink).

Adding NTP folks.
It looks like there's a full-contents solid-white PictureLayerImpl causing the problems. Trying to find where it came from in Blink.

Comment 34 by Deleted ...@, Apr 27 2015

I like to have some confidence that we are defining the problem correctly.
Please refer to this video:

1:27 to 1:41 - Firefox, no white flash
2:32 to 2:43 - Chrome, brilliant white flash

It is the BRILLIANT pangs of white flashes, whether it is opening a tab or clicking on the next link. Thank you.

Comment 35 by, Apr 29 2015

I am wondering why it's not fixed yet. Whenever I open page at night as now, my eyes get hurt because of white page.
It appears that the solid-white layer is CompositedDeprecatedPaintLayerMapping::m_graphicsLayer (tracing back from the cc::PictureLayerImpl that created a solid white quad, to the cc::PictureLayerImpl that pushed to it, to the cc::PictureLayer that pushed into that, to the blink::GraphicsLayer that created that). Methodology may be suspect.

I haven't figure out why the picture for the layer is all-white, though. CompositedDeprecatedPaintLayerMapping::layoutObjectBackgroundColor often returns white, but when I override it to always return, like, green, I still see a white flash.

Continuing to poke with stick.

Comment 37 by Deleted ...@, May 5 2015

chris, appreciate the digging
Owner: ----
Status: Untriaged
I'm not working on this, so making this Untriaged. Please feel free to take over. Thanks!

Comment 39 by, May 5 2015

Three years later and this thread/issue still lives. Nice. Thanks for looking into it!
Labels: Cr-Blink-Compositing Cr-Blink-Paint
The original Cr-UI labels don't seem to be relevant to the root cause.  Those with the expertise to fix this either have more important work, or aren't aware about this.  Adding Cr-Blink labels to garners more attention from experts.

Comment 41 by Deleted ...@, May 20 2015

Any news on this one?
I'm so sick of Firefox and I want to switch to Chrome, but this 'bug' is preventing me from doing so. It's like a stun grenade (flashbang), it hurts my eyes.

Comment 42 by Deleted ...@, May 28 2015

chris was last seen poking with stick

Comment 43 by Deleted ...@, Jun 11 2015

we are losing momentum again here...

Comment 44 by Deleted ...@, Jun 26 2015

any updates?
They have ignored this issue for years. Switch to firefox. FF is unstable,but no eye hurting at least.

Comment 46 by Deleted ...@, Jul 12 2015

Status: Available
Labels: Hotlist-Polish
Labels: -Cr-Blink-Compositing -Cr-Blink-Paint
Status: Assigned
This is a bug in the NTP itself, it does:

which sets the background color of the body based on the theme, but it does it async in some JS in an iframe's load event or DOMContentLoaded for the local NTP, or in other async JS for the remote NTP.

Perhaps the browser should be using the ThemeBackgroundInfo to set the background color of the tab before loading the NTP?

In any case there's nothing wrong with blink here, the NTP page is white until that async JS runs.

dbeam@ I'm not sure this is really your realm, but maybe you know who can fix this? :)

Comment 52 by, Aug 26 2015

> maybe you know who can fix this?

if I had to take a wild guess, probably the people in:

and those that have been working on the [actual] NTP lately (i.e. fserb@)

Comment 53 by, Aug 28 2015

the issue is that the background color of the page is being set by JS:

JS is not guaranteed to run before the first paint (used to be, not anymore).

if the background color gets applied earlier via HTML + CSS like this:

  <!-- in the source of chrome-search://local-ntp/local-ntp.html -->
  <style> body { background: /* insert theme color here */ } </style>

or with a <link> to dynamic stylesheet:

  <!-- i_know_the_bgcolor.css would be a dynamically generated response from C++ -->
  <link rel=stylesheet href=chrome-search://i_know_the_bgcolor.css>

the flash will go away.  i'm not sure how to fix for the online NTP, though.

fwiw: this does happen on chrome://apps as well, I just never use dark themes.

Comment 54 by, Aug 28 2015

fwiw: data:text/html,<body bgcolor=black> loads without any white flicker, so I know it's possible

Comment 55 by, Aug 28 2015

this will help for chrome://apps[1], but chrome://newtab uses ALL the JS

Project Member

Comment 56 by, Aug 28 2015

The following revision refers to this bug:

commit 7d89c927fb0f77fc4d9a8bc8cd93e6807722d39c
Author: dbeam <>
Date: Fri Aug 28 15:56:32 2015

Reduce (or remove?) blinding white flash on chrome://apps
BUG= 126341 

Review URL:

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


Mohammad, could you please try to repro this?
Unable to repro this bug on Beta 46.0.2490.33 and Canary 47.0.2510.0 /win and Mac . Thanks

Comment 59 by, Oct 10 2015

I'm easily able to reproduce this still on 46.0.2490.64 beta...
I have decided to switch to Firefox, which provides a solution to this problem.

In Firefox, go to the url about:config, type browser.display.background_color, and change this value from #FFFFFF (white) to a darker color like #333 (grey).


Comment 61 by, Oct 13 2015

Mergedinto: 21798
Status: Duplicate
It seems this has been around for a while.
I'm looking into it.
Yepp works in Firefox, but I like chromium... =/

Comment 63 by Deleted ...@, Dec 24 2015

Please also refer to
chris seems to know something about fixing it.

Comment 64 by, Jul 30 2016

I too prefer Chrome over Firefox, but this is still an issue in Chrome v52 :(
Any update on this?  Using a dark theme, I get blinded by flash grenades every time I open a new tab.

Comment 66 by, Jan 14 2017

I'm a programmer staring at screens all day.  This bug forced me back to Firefox; I was going blind with all the flashbangs.  I can't believe this ticket has been open for 3+ years.
why can't this be configured?!? please, someone find a way.

Comment 68 by, Jan 24 2017

Labels: Restrict-AddIssueComment-EditIssue
please see  bug 21798  instead of commenting on this one

Sign in to add a comment