Confirmed, doesn't happen all the time, but very often.
On such an "unopened" page pressing "home" button and then "back" opens the originally desired page sufficiently as a workaround.

 Issue 791370 

 Issue 791370  has been merged into this issue.

 Issue 791370  contains a repro that works every time. Seems to be an m64 regression, needs a bisect.

Unable to reproduce the issue on Win-10 using chrome reported version #64.0.3282.3 and latest canary #64.0.3282.5 by following the steps in comment #0 and steps in the merged  issue 791370 .
But the issue was seen sometimes on maximising already minimised chrome windows. The window appeared complete white. This is a very inconsistent behaviour which doesn't seem to happen every time.
Attaching screencast for reference.
Hence, marking it as untriaged for further investigation from dev team.

Thanks...!!

Deleted: 791342.mp4 5.2 MB

	791342.mp4 5.2 MB View Download

I have this right now with "65.0.3285.0 (Official Build) canary (64-bit) (cohort: Clang-64)" after a fresh reboot. It's amazingly frustrating. Moving from tab to tab often gets Chrome into this state. Opening a new tab seems to generally work, but then it's lost when I tab away and back.

As I wave my mouse over the tab, I see the pointer changing as it goes over various elements, so Chrome at least knows there's a tab there.

Able to reproduce this issue on reported version 64.0.3282.3 and latest canary 65.0.3285.0 using Windows 10 with steps mentioned in comment#0 and in  issue 791370 .

But issue is seen only once in 10 times. Unable to provide bisect as issue is inconsistent. Could someone from Blink>Paint team take a look into this issue.

Thanks!

krajshree@chromium.org, The spoken bug appears to only occur on Chrome Canary, not the stable Chrome version.

Bumping to P0. Chrome is unusable. I'm losing my mind. I haven't been able to repro on Dev 64.0.3278.0 yet. I have 6 browser windows with prolly > 60 tabs open across them. It sorta seems like closing some tabs makes ctrl-tabbing between tabs bring some back, but it isn't reliable.

Oh: I have no idea where to even start looking to debug this. I'm happy to break into my browser with windbg if someone gives me some ideas. Thanks.

This is not painting, this is most likely scheduling of some kind.

I can't repro with latest chromium build 64.0.3282.0 (Official Build) (64-bit) rev 5fdc0fab22ce7efd32532ee989b223fa12f8171e, for a bisect.

My reliable repro still happens on chrome canary 65.0.3285.0 (Official Build) canary (64-bit) (cohort: Clang-64) rev 2743a763a7e0772fef48cf852925f32b50ac04aa. The best way to repro is pin a few tabs then close and restart browser - the pinned tabs that are loaded in the background will show white as per previous comments.

Could this be a field trial?

here are my variations:

fe69e053-94941f92
16e0dd70-3f4a17df
f113d3c9-45dad6b4
1e528f0f-f23d1dea
b130ecb8-1410f10
6025934e-3f4a17df
7c1bc906-b5809d46
d52c4ff7-f23d1dea
3eb101d6-f23d1dea
3753beef-3f4a17df
47e5d3db-3d47f4f4
1c752ce9-ca7d8d80
a5cb8590-3f4a17df
34d450b1-f23d1dea
459a590c-2cec5d20
19c1fdaf-ca7d8d80
3042ad4b-ca7d8d80
591576c8-2f2d0be0
57f575bb-f23d1dea
e4e9ce8f-3f4a17df
b72f69e9-3f4a17df
f347910c-65bced95
4b61504a-d92031a1
77bbdddc-e08c81ee
5485fc4d-ca7d8d80
9773d3bd-4fbbdb50
93731dca-e89d496c
8fa604e0-2f2d0be0
8e3b2dc5-6403c7e4
a428bf14-b23b1b55
9e5c75f1-e406a769
350fabdd-1cf80f06
3de1fbf2-f23d1dea
f79cb77b-3f4a17df
47edb3-566ebc9b
274c53f-3f4a17df
4ea303a6-2b1a91b5
d92562a9-78c337f0
90bcbadc-f2347bb2
447469ba-968d9885
7aa46da5-c946b150
2b33233e-f23d1dea
6973a1cf-3f4a17df
72606c4f-3f4a17df
1aecb842-f23d1dea
cac0a91c-ca7d8d80
ad6d27cc-1627c3cf
757a5d98-ad6bc242
f3ea30a0-27a0c3c6
23496387-4ea78229
b2f0086-870290a7
3038aa2e-cf4f6ead
2d871858-3f4a17df
344833e9-1525b35b
4bc337ce-504c1843
1354da85-ca7d8d80
494d8760-d1cce074
3ac60855-3ec2a267
f296190c-36c69439
4442aae2-4ad60575
ed1d377-e1cc0f14
75f0f0a0-4ad60575
e2b18481-7564fb06
e7e71889-e1cc0f14
34baa302-c306c9a2
f5fff3a2-3f4a17df
81c6897f-870290a7
9cade933-f23d1dea
493ac2c5-ca7d8d80

hmm it seems --fake-variations-channel doesn't actually fake the channel..? The variations on my bisecting build are much shorter:

3095aa95-3f4a17df
6c43306f-ca7d8d80
7c1bc906-f55a7974
47e5d3db-3d47f4f4
b1edbc38-c306c9a2
d43bf3e5-bd7cd813
9773d3bd-f23d1dea
8e3b2dc5-93702590
9e5c75f1-1039a221
f79cb77b-3f4a17df
4ea303a6-ecbb250e
d92562a9-ca7d8d80
447469ba-13d9f35f
7aa46da5-c946b150
25fc488a-4d2fac87
1bced4a3-ca7d8d80
b2f0086-93053e47
ef25c1eb-ca7d8d80
4bc337ce-612a79a3
494d8760-d1cce074
f47ae82a-86f22ee5
3ac60855-3ec2a267
f296190c-d2276ecd
4442aae2-d7f6b13c
ed1d377-e1cc0f14
75f0f0a0-6bdfffe7
e2b18481-75cb33fc
e7e71889-e1cc0f14
94e68624-803f8fc4
da4aaa01-ca7d8d80

through a process of brute force, windiff, trial and error, searching critique for fieldtrial configs, flipping random features on off - I have determined that SurfaceSynchronization feature is causing this issue.

with --disable-features=SurfaceSynchronization - the problem goes away.

While I'm here - this is another plea to please raise the priority of issue 694675 - this is another case where not being able to accurately replicate a particular canary installation feature/field-trial configuration for the purposes of doing a bisect made this bug much harder to diagnose.

This is a bug in surface synchronization which is on a finch trial. The purpose of the finch trial is to catch bugs like this before the features launches to a large group of people.

I appreciate the feedback here but given this does not impact non-canary users and will not hit beta or stable without a fix, I'm switching this to P2. Please let me know if you object to this prioritization. I have every intention of fixing this soon, but this is not P0.

RBD is Pri-1. Agree this is not Pri-0.

Thank you all for debugging. Can we turn this finch experiment off? We are aiming for a Dev release tomorrow.

Does anyone mind my keeping it on in canary (to collect bugs) while turning it off for dev? Should be a simple change to a JSON file.

Dev release is now on Thursday 12/7 (since M63 stable is now planned for tomorrow). So would be good to have the experiment turned off before.

I think I know what's happening here. We open up a few tabs in the background and frame eviction kicks in so we lose the CompositorFrame, when we show the page again, we don't request a new CompositorFrame, I think. 

I have a fix locally (1 line of code!). I'm working on a unit test now.

I think I can land the fix today and I won't need to turn off the finch trial for dev. 

Patch in flight: https://chromium-review.googlesource.com/c/chromium/src/+/809935

Regarding comment 21: since the problem was identified as being canary only, I agree that it's no longer a P0. I think P0 was appropriate during the "is the world on fire?" phase of the investigation since it effectively made canary unusable.

That said, I wish that the finch trial had been halted immediately upon discovery. It's my belief that a canary that's broken for more than one day will drive users away from the channel, which hurts everyone relying on data from canary usage.

Is there concern for dev? If the fix misses the build, won't 50% of dev channel be broken? What do you think of backing off the finch trial now (at least for dev) and bringing it back once you're confident that it's safe?

As per comment#29 patch already submitted for review. Hence removing Needs-Bisect label

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

commit 13c92a34e96fb2a23f01d7c8c08c909a465c97de
Author: Fady Samuel <fsamuel@chromium.org>
Date: Wed Dec 06 16:08:36 2017

Surface synchronization: Update primary surface on Show

If a view is shown then it should have a primary surface. Today,
the primary surface may be lost due to frame eviction but we don't
re-set it on showing a view and so it was possible to end up with
an empty tab.

Bug:  672962 ,  791342 
Change-Id: I0ade2a58e9b78e82011e81af441a406b872b7710
Reviewed-on: https://chromium-review.googlesource.com/809935
Reviewed-by: Saman Sami <samans@chromium.org>
Commit-Queue: Fady Samuel <fsamuel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522100}
[modify] https://crrev.com/13c92a34e96fb2a23f01d7c8c08c909a465c97de/content/browser/renderer_host/delegated_frame_host.cc
[modify] https://crrev.com/13c92a34e96fb2a23f01d7c8c08c909a465c97de/content/browser/renderer_host/render_widget_host_view_aura.h
[modify] https://crrev.com/13c92a34e96fb2a23f01d7c8c08c909a465c97de/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

This should be fixed now. I'd like to merge this back into M64! Thanks

> That said, I wish that the finch trial had been halted immediately upon discovery. It's my belief that a canary that's broken for more than one day will drive users away from the channel, which hurts everyone relying on data from canary usage.

Stopping the trial while there are known bugs like this active seems very reasonable to me, and reactiving it when they are fixed. I think the point of the trial is to be able to turn it on/off quickly?

The bug has been fixed. I did send out a CL to disable this trial for dev. I'd like to keep it running in canary as long as I can fix the bug within 24 hrs of discovering it.

I think in general the practice with Chromium is to 'revert early' and not to hold off a revert if a reproducible bug is found, while the bug is being fixed.

This is because it's sometimes hard to predict how long it will take to fix a bug, whether the fix will actually hold - and while the bug is still manifesting for any user, that's the impact that matters here, especially when it can result in users being pushed off early channels (and it's hard enough to keep them there - shout out to 90iz80 for reporting this bug! Thanks for making our product better!).

TL;DR: I support #30 and #33 - in particular I think after #20 the field trial should have been deactivated on all channels and then re-enabled (with a min-version being the version(s) the bug is fixed in) once the fix has been landed, reached a Canary and correct behavior verified.

That's fair. in the future, I will disable the trial as soon as I find out about a bug and re-enable as soon as the fix lands with a new min version.

FWIW, the fix has landed for this one, and I've disabled the trial on dev.

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

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

fsamuel@, can you please merge the above fix to M64 branch: 3282 if required? Per c#37, the trial has been disabled on 'Dev' not sure whether it's applicable to whole 3282 branch even if it promotes to 'Beta' & 'Stable'?

Thank you!

Let's let it run for a bit longer on Canary, and let's re-visit the merge on Monday. I would like to confirm if this is fully safe and well tested before merging. 

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

How does this look in Canary? If it looks good, then please go ahead and merge to M64. Branch:3282.

I've merged a better solution in https://chromium-review.googlesource.com/c/chromium/src/+/820175.

Does this not need to be merged then?

Removing Merge-Approved-64 label. If this needs to be merged, then please re-apply.