I can't reproduce this on 10.14.1 with 73.0.3633.0.

a) Can you try 73.0.3633.0?
b) If you can get this to happen, can you check the page with devtools to see if the page structure is mssed up? I notice that the top bar is missing as well.

Updated to  73.0.3633.0 and it still happens.

This is clearly a rendering problem, not a DOM problem. When opening DevTools the page shows perfectly again.

See attached video for repro.

Deleted: text-render.mov 5.9 MB

	text-render.mov 5.9 MB View Download

Okay, thanks. Into GPU triage queue.

Not Mac-specific. Happens on ChromeOS too:

Google Chrome	72.0.3623.3 (Official Build) dev (64-bit)
Revision	62566d37ac342c0932ceb403043dc1ab699fc21d-refs/branch-heads/3623@{#7}
Platform	11307.0.0 (Official Build) dev-channel eve

+couple other paint and compositing folks.

This would seem to be a failure to re-draw or commit after DeferCommits has kicked in on tab hide. Reasonable theory?

Bisects to https://chromium.googlesource.com/chromium/src/+log/4768f623aa44c968f24ec0666b12ddf706f83d7d..7a3974157d66427d15e731954c74c7c0038e81f6

The most plausible candidate, by far, is ...
cc/gpu: Add client driven paint caching for OOP raster.
commit	33205a780d892f1ae0af639fd57a339f44093f9a
author	Khushal <khushalsagar@chromium.org>	Thu Nov 08 10:12:29 2018

This is a serious bug. Revert the patch?

Khushal is out for the next couple weeks.

From a quick check, this appears to be OOP-Raster specific (and that would align with Khushal's patch).

I suspect that the patch you point out has a bug which is causing us to try to use font entries which have been evicted.

We're hitting the error here: https://cs.chromium.org/chromium/src/gpu/command_buffer/service/raster_decoder.cc?rcl=667e92ed486d1326e4af0c9f1f68d9cb1c3b38d3&l=2297

Unfortunately, this patch doesn't really revert cleanly at this point.

OOP-Raster is not launched on Mac or CrOS, but is in a finch trial. If we want to address this bug in Canary or Dev, our best bet is probably to disable the experiment on Mac / CrOS for now and investigate the issue when Khushal returns.

WDYT?

Also worth noting, OOP-R is attempting to launch on Android in M71, so an M72 regression is problematic. That said, I couldn't trigger the bug on Android. I imagine it exists there as well though.

We should try to rapidly fix this issue and merge to M72 once Khushal gets back. I'll investigate more if I have time, but don't have a lot of bandwidth at the moment.

I'll take a look tomorrow.

Reminder M72 Stable is coming soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure to land the fix and request a merge into the release branch ASAP. Thank you.

Reminder M72 Stable is coming VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure to land the fix and request a merge into the release branch ASAP. Thank you.

Issue 912167 has been merged into this issue.

 Issue 906979  has been merged into this issue.

Fix up for review: https://chromium-review.googlesource.com/c/chromium/src/+/1393138

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

commit 9192c6f341d55098b34a3254ed9938307b00fabe
Author: Khushal Sagar <khushalsagar@chromium.org>
Date: Thu Jan 03 11:41:10 2019

cc/gpu: Ensure consistent PaintCache state on op serialization failure.

The ClientPaintCache assumes that once an entry has been added to its
state tracking, it is guarenteed to be transferred to the service side
cache and is removed only when explicitly purged.

This assumption is not true in the case where serializing an op fails
due to insufficient memory. In this scenario, the memory is remapped
and the op is re-serialized but any changes made to the
ClientPaintCache state, supposed to be a mirror of the service side
state, are not actually made to the service side state. This cause the
Client and Service PaintCaches to get in an inconsistent state and we
fail to raster the tile due to deserialization failures.

Avoid this by tracking the serialized cache entries in a pending list
that is committed only when the data is guarenteed to be transferred to
the service, and discarded otherwise.

R=enne@chromium.org, ericrk@chromium.org

Bug:  912282 
Change-Id: I96d4108acb4903ce0ff48b54718c65b61805e103
Reviewed-on: https://chromium-review.googlesource.com/c/1393138
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#619622}
[modify] https://crrev.com/9192c6f341d55098b34a3254ed9938307b00fabe/cc/paint/paint_cache.cc
[modify] https://crrev.com/9192c6f341d55098b34a3254ed9938307b00fabe/cc/paint/paint_cache.h
[modify] https://crrev.com/9192c6f341d55098b34a3254ed9938307b00fabe/cc/paint/paint_cache_unittest.cc
[modify] https://crrev.com/9192c6f341d55098b34a3254ed9938307b00fabe/cc/test/test_options_provider.cc
[modify] https://crrev.com/9192c6f341d55098b34a3254ed9938307b00fabe/gpu/command_buffer/client/raster_implementation.cc

Checked with mac canary version 73.0.3663.0 and OOP Raster enabled, the bug is fixed with the change in #17. Making a merge request for 72.

Approving merge to M72 branch 3626 based on comment #18 and per offline chat with khushalsagar@.

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

commit a05298e0fe94d85ff865192fb4b907470ec447d2
Author: Khushal Sagar <khushalsagar@chromium.org>
Date: Mon Jan 07 06:19:55 2019

cc/gpu: Ensure consistent PaintCache state on op serialization failure.

The ClientPaintCache assumes that once an entry has been added to its
state tracking, it is guarenteed to be transferred to the service side
cache and is removed only when explicitly purged.

This assumption is not true in the case where serializing an op fails
due to insufficient memory. In this scenario, the memory is remapped
and the op is re-serialized but any changes made to the
ClientPaintCache state, supposed to be a mirror of the service side
state, are not actually made to the service side state. This cause the
Client and Service PaintCaches to get in an inconsistent state and we
fail to raster the tile due to deserialization failures.

Avoid this by tracking the serialized cache entries in a pending list
that is committed only when the data is guarenteed to be transferred to
the service, and discarded otherwise.

R=​enne@chromium.org, ericrk@chromium.org

Bug:  912282 
Change-Id: I96d4108acb4903ce0ff48b54718c65b61805e103
Reviewed-on: https://chromium-review.googlesource.com/c/1393138
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#619622}(cherry picked from commit 9192c6f341d55098b34a3254ed9938307b00fabe)
Reviewed-on: https://chromium-review.googlesource.com/c/1395871
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#578}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
[modify] https://crrev.com/a05298e0fe94d85ff865192fb4b907470ec447d2/cc/paint/paint_cache.cc
[modify] https://crrev.com/a05298e0fe94d85ff865192fb4b907470ec447d2/cc/paint/paint_cache.h
[modify] https://crrev.com/a05298e0fe94d85ff865192fb4b907470ec447d2/cc/paint/paint_cache_unittest.cc
[modify] https://crrev.com/a05298e0fe94d85ff865192fb4b907470ec447d2/cc/test/test_options_provider.cc
[modify] https://crrev.com/a05298e0fe94d85ff865192fb4b907470ec447d2/gpu/command_buffer/client/raster_implementation.cc

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

Commit: a05298e0fe94d85ff865192fb4b907470ec447d2
Author: khushalsagar@chromium.org
Commiter: khushalsagar@chromium.org
Date: 2019-01-07 06:19:55 +0000 UTC

cc/gpu: Ensure consistent PaintCache state on op serialization failure.

The ClientPaintCache assumes that once an entry has been added to its
state tracking, it is guarenteed to be transferred to the service side
cache and is removed only when explicitly purged.

This assumption is not true in the case where serializing an op fails
due to insufficient memory. In this scenario, the memory is remapped
and the op is re-serialized but any changes made to the
ClientPaintCache state, supposed to be a mirror of the service side
state, are not actually made to the service side state. This cause the
Client and Service PaintCaches to get in an inconsistent state and we
fail to raster the tile due to deserialization failures.

Avoid this by tracking the serialized cache entries in a pending list
that is committed only when the data is guarenteed to be transferred to
the service, and discarded otherwise.

R=​enne@chromium.org, ericrk@chromium.org

Bug:  912282 
Change-Id: I96d4108acb4903ce0ff48b54718c65b61805e103
Reviewed-on: https://chromium-review.googlesource.com/c/1393138
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#619622}(cherry picked from commit 9192c6f341d55098b34a3254ed9938307b00fabe)
Reviewed-on: https://chromium-review.googlesource.com/c/1395871
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/branch-heads/3626@{#578}
Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}

A note to the test team. Please make sure you go to chrome://flags and enable the feature "Out of process rasterization" when verifying the fix. Thanks!