Attaching logs. I see some drm warning, but I can confirm that it is not always the case when I see the issue.

Deleted: debug-logs_20170829-183843.tgz 3.2 MB

debug-logs_20170829-183843.tgz 3.2 MB Download

I also see this on link 9895.0.0 canary.  Maybe related to https://chromium-review.googlesource.com/634161 ?  Haven't noticed any graphics-related regressions on any web pages yet.

i'm going to claim graphics corruption.  i upgraded my samus to 9895.0.0 and i can reproduce the failure.  when i deployed crosh-extension-0.8.36.4-r78, i continue seeing the bad behavior.  that's from earlier this year:
  commit a2f30ee08fb8f7d0440ba7056d95591f146bcd04
  Author: Mike Frysinger <vapier@chromium.org>
  Date:   Thu May 18 20:17:06 2017 -0400

further more, the weird double display isn't visible from the chrome dev inspector.  if i delete all the content from the html side, there is still text being rendered, but it isn't in the DOM.  looks like it's "in the background image".  switching tabs at any time causes the background corruption to clear itself.

someone should bisect the OS versions down a bit more to see when this started :).

now i'm certain it's a graphics problem.  my lumpy just upgraded to Version 62.0.3198.0 (9887.0.0) and i'm seeing the same corruption with Secure Shell.  it was working just fine before the reboot.  going by UE logs, i was on 9869.0.0 previously.

Nicolas just reported it on poppy using 9885.0.0.  so i guess that narrows our window down a little more:
  9869.0.0 good (lumpy)
  9872.0.0 good (samus & poppy)
...to be bisected...
  9885.0.0 bad (poppy)
  9887.0.0 bad (samus & lumpy)
  9895.0.0 bad (samus)

since it's trivial to reproduce, i'll idly try bisecting with some recovery images on my samus.

Tiles are getting mixed up, probably a problem on the compositor side.

see https://bugs.chromium.org/p/chromium/issues/detail?id=759148 also, might be the same (compositor tiles getting mixed up)

bisecting samus recovery images:
  9872.0.0 good
  9873.0.0 good
  9876.0.0 good
  9878.0.0 good
  9879.0.0 good 62.0.3195.0
  9880.0.0 bad  62.0.3197.0
  9885.0.0 bad

here's the CrOS changes in that range:
  https://crosland.corp.google.com/log/9879.0.0..9880.0.0

here's the Chrome changes:
  https://chromium.googlesource.com/chromium/src/+log/62.0.3195.0..62.0.3197.0

that's a ton though.  needs someone to bisect Chrome builds down further.

This is happening on my Caroline too 

opening to the public since external users are running into this, and the attached screenshot in comment #0 doesn't leak anything (has a few part names in the dmesg, but i don't think they're interesting</last words>).

This should only block beta, it is too late to save dev.

feedback report here: https://feedback.corp.google.com/product/208/report/72053160699

 Issue 760192  has been merged into this issue.

I'll bisect Chrome this morning if nobody else is on it.

f5fb596736f90c3e00f8f2aa70daea555e8bb664 is the first bad commit
commit f5fb596736f90c3e00f8f2aa70daea555e8bb664
Author: Steve Kobes <skobes@chromium.org>
Date:   Sat Aug 26 00:01:39 2017 +0000

    Refactor BoxPaintInvalidator::InvalidateScrollingContentsBackgroundIfNeeded.
    
    This method was doing five things with confusing flow:
    
    (1) deciding what type of background invalidation was needed
    (2) updating paint invalidation bits on the LayoutBox
    (3) issuing the paint invalidation on the GraphicsLayer
    (4) setting the PaintLayer::NeedsRepaint() flag
    (5) clearing the layer's DisplayItem cache
    
    I have extracted (1) into a separate method and moved (2) into InvalidatePaint,
    leaving only (3), (4), and (5).  There is no change in behavior.
    
    Bug:  734187 
    Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
    Change-Id: I03aa84f27189a997cb02a7a3c5186f94a33c5a34
    Reviewed-on: https://chromium-review.googlesource.com/633851
    Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
    Commit-Queue: Steve Kobes <skobes@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#497601}

Issue seems to be fixed on Chromium ToT: 22e444176a93754a233f1942bd48dedff9b13ba7 does not show the issue.

This looks like the fix:

commit 14e906a67f9ae321535d917a486c14a17b7ea3cb
Author: Steve Kobes <skobes@chromium.org>
Date:   Wed Aug 30 00:31:29 2017 +0000

    Fix repaint of scrolling contents layer on layout overflow change.
    
    If a composited scroller with a solid-color background has its layout overflow
    rect resized, the scrolling contents layer needs a paint invalidation.
    
    This broke in r497601, which made the scrolling contents layer's invalidation
    conditional on BackgroundGeometryDependsOnLayoutOverflowRect.
    
    Bug:  759436 ,  734187 
    Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
    Change-Id: I6dd689dc6766bf76cc4c6d7a3915e0cd2202cda6
    Reviewed-on: https://chromium-review.googlesource.com/639011
    Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
    Commit-Queue: Steve Kobes <skobes@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#498305}

Landed in Chromium 62.0.3200.0.

Fixed on soraka Chrome OS canary 9898.0.0 (Chrome 62.0.3201.0).

(I guess I should have tried that first ,-( )