schenney@:
Yes, the extension manifest is up to date (version 2). 
But the extension is not packed or anything, just zipped. So you would need to unzip it and then open the contained dir ('white-flash'). Just checked again. It is working.

I am working on Linux (Ubuntu 16.04).
Right now, I cannot test the issue on other platforms. Sorry. 
Would be nice if someone else could do that.

Thank your very much for your quick response and opening a new bug. 

I am so happy that this work. I use window 7 :)

Just to clarify: At least on Linux the white flash is back with version 66. 

(What I meant by 'is working' in comment 2, is that the attached demo extension should be installable via Chrome's extension page. The comment might be misleading. My bad.)

@vanhoang: 
Could you be more specific:
On which version of Chrome did you test it?
Did you install the attached extension? 
What happened when you opened a new tab?

schenney@ can you help triage this?

I can't really help triage. I don't know who might be able to fix it. The Component owners should be picking up untriaged bugs.

Copying from https://bugs.chromium.org/p/chromium/issues/detail?id=470669#c356:
"This worked perfectly in version 65 and is now broken in version 66."

Could we get test confirmation on that and a bisect?

Able to reproduce the issue on reported chrome version 66.0.3359.139, beta# 67.0.3396.30 and latest chrome 68.0.3422.0 using Windows-10, Ubuntu 14.04  hence providing Bisect Info
Note: Able to reproduce the issue on Mac 10.12.6 on chrome revision 66.0.3359.139 and latest chrome 68.0.3422.0 and the issue is seeing from M-60(60.0.3112.0).
Bisect Info:
================
Good build: 66.0.3330.0
Bad build: 66.0.3331.0

You are probably looking for a change made after 531712 (known good), but no later than 531713 (first known bad).
https://chromium.googlesource.com/chromium/src/+log/be9f9f40f79fae8528cd9e5f5fc578c71dc2e545..f7731345b34fd9f87ce5792f5f952f8e5cdfaac8
Reviewed-on: https://chromium-review.googlesource.com/855256

@Saman Sami: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable.

Thanks!

If the bisect is correct I doubt this is a new issue. My CL only slightly increases load time in some cases and therefore the flash might become more noticeable. Currently we flash theme color but if we flash previous tab's color (as we used to do) it might become less noticeable.

Hi there!

In Version 65 it was even possible to load an inline (data-url) background image in a new tab page without seeing a white flash or a flash of some other color. 
So I doubt that changing the color of the flash brings us back to how things were in version 65. 
It seems to me that there is some 'new delay' before the page is rendered since version 66.

I am not a Chrome developer so this might be very naive, but I wondered if it might be possible to fix this kind of rendering issue once and for all with an approach like this:

* If the user opens a local file (or extension page or theme) in a new tab, then do not show (=hide) the new tab 'until the js event DOMContentLoaded' is fired.
* If the user opens a local file (or extension page or theme) in a new window, then do not show (=hide) the new window 'until DOMContentLoaded' is fired.
* If - for some reason - DOMContentLoaded isn't fired after 150ms or so then show the new tab / window anyway.

'Flashing other colors' (from the theme or a previous tab) before the rendering starts seems like a hacky fix to me. But again, I am not an expert so this might be a naive idea. 

I would be curious to learn why this can't be fixed this way. Or can it?


Thanks!

We do actually have a similar system but it doesn't seem to work as intended... I'm working on a fix.

I see. Thanks!

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

commit 52e45765d50a03b7833097e09446e287e26c94c1
Author: Saman Sami <samans@chromium.org>
Date: Mon May 07 23:06:28 2018

Don't reset the deadline in DelegatedFrameHost if size hasn't changed

We should only reset the deadline when ui is resizing because OS is
guttering us anyways. In other cases use the real deadline.

Bug:  834449 ,  672962 
Change-Id: I95a29e3cf8a508d0d1cd614df79c0e12183f1487
Reviewed-on: https://chromium-review.googlesource.com/1048206
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556600}
[modify] https://crrev.com/52e45765d50a03b7833097e09446e287e26c94c1/content/browser/renderer_host/delegated_frame_host.cc

Tested the issue on latest chrome 68.0.3424.0 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome version and installed the extension provided in comment#0
2) Clicked on New Tab Page, seen white flash before New Tab Page
Observations: Also tested the issue on Mac 10.12.6 and Windows-10, seen same behaviour as mentioned above

@Saman Sami: Please find the attached screencast for your reference and help us in confirming the fix.

Thanks!

Deleted: CL - 834449.ogv 2.5 MB

	CL - 834449.ogv 2.5 MB View Download

Thank you for testing, but this issue is not supposed to be fixed yet. I should be able to land a fix today.

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

commit 39a1111b6cf57987d92b01848170c05e38e4d20f
Author: Saman Sami <samans@chromium.org>
Date: Tue May 08 22:35:46 2018

Don't allocate new LocalSurfaceId for the first navigation

Don't allocate a new id for the first navigation. The browser might
have already embedded the old surface so if the renderer doesn't submit
to the old surface there will be a flash.

Bug:  834449 
Change-Id: Ie9e79dba0b8afcfb43929c8264cc7e3c2c4a0792
Reviewed-on: https://chromium-review.googlesource.com/1048118
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556988}
[modify] https://crrev.com/39a1111b6cf57987d92b01848170c05e38e4d20f/content/browser/renderer_host/browser_compositor_view_mac.h
[modify] https://crrev.com/39a1111b6cf57987d92b01848170c05e38e4d20f/content/browser/renderer_host/browser_compositor_view_mac.mm
[modify] https://crrev.com/39a1111b6cf57987d92b01848170c05e38e4d20f/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/39a1111b6cf57987d92b01848170c05e38e4d20f/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/39a1111b6cf57987d92b01848170c05e38e4d20f/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

This should be fixed. Please reopen if I'm wrong.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-67; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-67 label, otherwise remove Merge-TBD label. Thanks.

Which CL need a merge to M66, only listed at #20 or listed at #17 as well? How critical it is to merge to M66 and how safe it is?

Are we re-spinning M66? How many days do we have left? I think merging into M67 should be good enough.

I'm sorry, comment #23 was for M67 (not M66). 

+ abdulsyed@ can comment on M66.

OK, I'll wait a few days then merge into M67. I did my best to make sure these CLs are as low-risk as possible.

Thank you samans@. 
Pls note we can approve these CLs merge to M67 only they are fully safe as M67 is going to stable soon and this is not M67 regression. 

Plan is to respin M66, but we are only 2 weeks away from 67. My preference for this is to land in 67. 

The NextAction date has arrived: 2018-05-10

How are the changes looking in canary?

I'm reopening this bug because I still see this issue on Mac (there is a possibility that this problem always existed on Mac, I need to check). Windows and linux look good though, so requesting merge for CLs in #17 and #20.

Pls update the bug with Mac result. 
Also wanted to double check, is this bug critical to fix for M67 as it is regressed in M66 which is currently in stable? 

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

I tried M65 on Mac and still saw this issue so my CL can't be at fault. Based on #11 this issue existed on Mac since M60.

#32: I don't believe extensions that override new tab page are common but the fixes seem low-risk to me so I would rather merge them back to M67.

Approving merge to M67 branch 3396 for for CLs in #17 and #20 based on comment #32 and #35. Please merge ASAP and mark bug as fixed after the merge. Thank you.

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

commit ec236a99f704a1f33243b56c1344b392675efef7
Author: Saman Sami <samans@chromium.org>
Date: Thu May 10 20:28:41 2018

Don't reset the deadline in DelegatedFrameHost if size hasn't changed

We should only reset the deadline when ui is resizing because OS is
guttering us anyways. In other cases use the real deadline.

TBR=samans@chromium.org

(cherry picked from commit 52e45765d50a03b7833097e09446e287e26c94c1)

Bug:  834449 ,  672962 
Change-Id: I95a29e3cf8a508d0d1cd614df79c0e12183f1487
Reviewed-on: https://chromium-review.googlesource.com/1048206
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#556600}
Reviewed-on: https://chromium-review.googlesource.com/1053886
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#817}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/ec236a99f704a1f33243b56c1344b392675efef7/content/browser/renderer_host/delegated_frame_host.cc

Cl listed at #37 is merged to M66 branch 3359 without approval. Pls revert ASAP.

CL was approved for M67 branch 3396 at #36. So please merge M67.

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

commit 6f99d721f053075416779afca37208ac0b350a11
Author: Saman Sami <samans@chromium.org>
Date: Thu May 10 20:34:23 2018

Revert "Don't reset the deadline in DelegatedFrameHost if size hasn't changed"

This reverts commit ec236a99f704a1f33243b56c1344b392675efef7.

Reason for revert: Wrong branch

Original change's description:
> Don't reset the deadline in DelegatedFrameHost if size hasn't changed
> 
> We should only reset the deadline when ui is resizing because OS is
> guttering us anyways. In other cases use the real deadline.
> 
> TBR=samans@chromium.org
> 
> (cherry picked from commit 52e45765d50a03b7833097e09446e287e26c94c1)
> 
> Bug:  834449 ,  672962 
> Change-Id: I95a29e3cf8a508d0d1cd614df79c0e12183f1487
> Reviewed-on: https://chromium-review.googlesource.com/1048206
> Reviewed-by: Fady Samuel <fsamuel@chromium.org>
> Commit-Queue: Saman Sami <samans@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#556600}
> Reviewed-on: https://chromium-review.googlesource.com/1053886
> Reviewed-by: Saman Sami <samans@chromium.org>
> Cr-Commit-Position: refs/branch-heads/3359@{#817}
> Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}

TBR=fsamuel@chromium.org,samans@chromium.org

Change-Id: I17883c526eba3bb10434f65d075a1e3488826153
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  834449 ,  672962 
Reviewed-on: https://chromium-review.googlesource.com/1054202
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#818}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/6f99d721f053075416779afca37208ac0b350a11/content/browser/renderer_host/delegated_frame_host.cc

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

commit 35b0331e14b95c50b21f8e87786e46ce3ba80e3c
Author: Saman Sami <samans@chromium.org>
Date: Thu May 10 20:46:37 2018

Don't reset the deadline in DelegatedFrameHost if size hasn't changed

We should only reset the deadline when ui is resizing because OS is
guttering us anyways. In other cases use the real deadline.

TBR=samans@chromium.org

(cherry picked from commit 52e45765d50a03b7833097e09446e287e26c94c1)

Bug:  834449 ,  672962 
Change-Id: I95a29e3cf8a508d0d1cd614df79c0e12183f1487
Reviewed-on: https://chromium-review.googlesource.com/1048206
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#556600}
Reviewed-on: https://chromium-review.googlesource.com/1054496
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#557}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/35b0331e14b95c50b21f8e87786e46ce3ba80e3c/content/browser/renderer_host/delegated_frame_host.cc

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

commit 45a041ca01e99bb0110f0a1a45fe366336f9dd0a
Author: Saman Sami <samans@chromium.org>
Date: Thu May 10 21:13:38 2018

Don't allocate new LocalSurfaceId for the first navigation

Don't allocate a new id for the first navigation. The browser might
have already embedded the old surface so if the renderer doesn't submit
to the old surface there will be a flash.

TBR=samans@chromium.org

(cherry picked from commit 39a1111b6cf57987d92b01848170c05e38e4d20f)

Bug:  834449 
Change-Id: Ie9e79dba0b8afcfb43929c8264cc7e3c2c4a0792
Reviewed-on: https://chromium-review.googlesource.com/1048118
Reviewed-by: Fady Samuel <fsamuel@chromium.org>
Commit-Queue: Saman Sami <samans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#556988}
Reviewed-on: https://chromium-review.googlesource.com/1054406
Reviewed-by: Saman Sami <samans@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#560}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/45a041ca01e99bb0110f0a1a45fe366336f9dd0a/content/browser/renderer_host/browser_compositor_view_mac.h
[modify] https://crrev.com/45a041ca01e99bb0110f0a1a45fe366336f9dd0a/content/browser/renderer_host/browser_compositor_view_mac.mm
[modify] https://crrev.com/45a041ca01e99bb0110f0a1a45fe366336f9dd0a/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/45a041ca01e99bb0110f0a1a45fe366336f9dd0a/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/45a041ca01e99bb0110f0a1a45fe366336f9dd0a/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

@samans: Thank you very much for your work! In #32 you reopened the bug because the white flash is (and might always been) visible on macOS. So is there any chance this could be fixed for macOS, too? Because that would be awesome.

I would like to test your fix on Ubuntu. I have installed the 'google-chrome-beta' deb repository which currently gives me Chrome in version "67.0.3396-40-1". 
Is this the version with your fix? If not, which version is it and when can I install it via the deb repository? Sorry, I am a noobie to bug reporting.

Thanks again.

You can try the Canary channel on Windows or wait for the next beta release (probably Wednesday?)

I'm not familiar with Mac so I don't think I can work on it, but feel free to file a separate bug and hopefully someone will look into it.

I see. Thank you very much!

@everybody here: 
As suggested in comment #45 I filed a separate bug report for macOS here:
https://bugs.chromium.org/p/chromium/issues/detail?id=842071

I don't own a Mac myself so it would be great if someone with a Mac could confirm the issue over there (@issue 842071).

Thank you!

Was this supposed to fix the white flash when switching tabs, or was this unrelated? The white flash when switching tabs is insanely annoying.

This bug has reached the ten years anniversary since the first report in 2008.
Congratulations!

Able to reproduce the issue on chrome version 66.0.3359.139
Verified the fix on Windows-10 and Ubuntu 14.04 using Chrome version #67.0.3396.99 as per the comment #0
Attaching screen cast for reference.
Observed "No white on opening new tab with extensions".
Hence, the fix is working as expected. 
Adding the verified labels.
As per comment# 47: a separate bug has been filed against Mac, hence providing TE-Verified labels for Linux and Windows

Thanks...!!

Deleted: 834449.ogv 1.0 MB

	834449.ogv 1.0 MB View Download

Assuming it's the same bug, the issue is not fixed.

https://bugs.chromium.org/p/chromium/issues/detail?id=853986