Not that I can capture anything at the time of the occurrence but I just did a feedback report. 2 minutes ago with this email address.

Just went through another lockup after trying a CTRL + SHIFT + screen resolution change. On reboot, Chrome freezes at the splash screen.
Acer R13 elm
This is absolutely reproducible. I am in developer mode and on Canary. This requires a Powerwash to recover (2 Powerwashes if going back to developer mode).
I am willing to do whatever steps might be needed to track this down.

 Issue 866017  has been merged into this issue.

 Issue 866288  has been merged into this issue.

If your screen stops updating, try pressing Control-Shift-0

https://chromium-review.googlesource.com/c/chromium/src/+/1150251

 Issue 867178  has been merged into this issue.

Merge approved for M69.

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

commit 48d26c3d8f9f81fe52e33abe390ba235e42b65bf
Author: Michael Spang <spang@chromium.org>
Date: Wed Jul 25 20:39:58 2018

Revert "Set correct pixel size for the compositor"

This reverts commit c1a826ab79d4303ddd87bbbf4f6d38995c4bcd36.

Reason for revert: Screen stops updating on some devices with non default scale factor

Bug:  866010 

Original change's description:
> Set correct pixel size for the compositor
> 
> Right now we clip(GL_SCISSOR) the display buffer based on the physical
> pixel size of the display. The pixel size we send to the ui compositor
> is the size we receive from the platform window(the display in Chrome
> OS). However, this may not be what we want if the platform has some
> fractional scale applied.
> 
> UI elements have their sizes set in DIP. If some UI element (ui::Layer)
> has its size set to the DIP size of the display, their scaled size
> (the pixel size after applying device scale factor) after rounding may
> not match the physical pixel size of the display. This difference may
> lead to 1px lines left unclipped. This happens in the case of the shelf
> whose width is set to the width of the display. For a device like eve
> where the internal display has a physical resolution width of 2400px,
> if a device scale of 1.8 is applied, the DIP width of the display
> becomes 1333. We set the bounds of the shelf to this. Now when we do
> the actual paint, we scale the shelf to its physical pixel size which
> is ROUND(1333*1.8) = 2399. At the same time the compositor will clip
> things at width 2400. This difference is what gives the shelf a 1px
> gap.
> 
> A proper way to fix this is to scale ui::Layer bounds such that it
> snaps to the parent's or displays edge similar to what pixel canvas
> does in views::View. However, that is a large change. In the meantime
> this patch sets the correct physical pixel size for the compositor so
> that correct clipping happens.
> 
> Bug:  843354 
> Change-Id: Ic9e055c0ba39d85a7297809baf946398bf09f40a
> Component: UI compositor, pixel canvas, scaling, HiDPI
> Reviewed-on: https://chromium-review.googlesource.com/1130495
> Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#575402}

TBR=oshima@chromium.org,thakis@chromium.org,malaykeshav@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  843354 
Change-Id: If6d8e5649f37ec2cece1411419ca2db61daf06c8
Reviewed-on: https://chromium-review.googlesource.com/1150251
Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578042}
[modify] https://crrev.com/48d26c3d8f9f81fe52e33abe390ba235e42b65bf/ash/host/ash_window_tree_host_platform.cc
[modify] https://crrev.com/48d26c3d8f9f81fe52e33abe390ba235e42b65bf/ash/host/ash_window_tree_host_platform.h
[modify] https://crrev.com/48d26c3d8f9f81fe52e33abe390ba235e42b65bf/ui/aura/window_tree_host.cc
[modify] https://crrev.com/48d26c3d8f9f81fe52e33abe390ba235e42b65bf/ui/aura/window_tree_host.h

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

commit 01f811977e700cbafa5cd3087b53cea6940dd23f
Author: Michael Spang <spang@chromium.org>
Date: Wed Jul 25 20:48:39 2018

Revert "Set correct pixel size for the compositor"

This reverts commit c1a826ab79d4303ddd87bbbf4f6d38995c4bcd36.

Reason for revert: Screen stops updating on some devices with non default scale factor

Bug:  866010 

Original change's description:
> Set correct pixel size for the compositor
>
> Right now we clip(GL_SCISSOR) the display buffer based on the physical
> pixel size of the display. The pixel size we send to the ui compositor
> is the size we receive from the platform window(the display in Chrome
> OS). However, this may not be what we want if the platform has some
> fractional scale applied.
>
> UI elements have their sizes set in DIP. If some UI element (ui::Layer)
> has its size set to the DIP size of the display, their scaled size
> (the pixel size after applying device scale factor) after rounding may
> not match the physical pixel size of the display. This difference may
> lead to 1px lines left unclipped. This happens in the case of the shelf
> whose width is set to the width of the display. For a device like eve
> where the internal display has a physical resolution width of 2400px,
> if a device scale of 1.8 is applied, the DIP width of the display
> becomes 1333. We set the bounds of the shelf to this. Now when we do
> the actual paint, we scale the shelf to its physical pixel size which
> is ROUND(1333*1.8) = 2399. At the same time the compositor will clip
> things at width 2400. This difference is what gives the shelf a 1px
> gap.
>
> A proper way to fix this is to scale ui::Layer bounds such that it
> snaps to the parent's or displays edge similar to what pixel canvas
> does in views::View. However, that is a large change. In the meantime
> this patch sets the correct physical pixel size for the compositor so
> that correct clipping happens.
>
> Bug:  843354 
> Change-Id: Ic9e055c0ba39d85a7297809baf946398bf09f40a
> Component: UI compositor, pixel canvas, scaling, HiDPI
> Reviewed-on: https://chromium-review.googlesource.com/1130495
> Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Commit-Queue: Malay Keshav <malaykeshav@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#575402}

TBR=malaykeshav@chromium.org, oshima@chromium.org, spang@chromium.org, thakis@chromium.org


(cherry picked from commit 48d26c3d8f9f81fe52e33abe390ba235e42b65bf)

Bug:  843354 
Change-Id: If6d8e5649f37ec2cece1411419ca2db61daf06c8
Reviewed-on: https://chromium-review.googlesource.com/1150251
Reviewed-by: Michael Spang <spang@chromium.org>
Commit-Queue: Michael Spang <spang@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#578042}
Reviewed-on: https://chromium-review.googlesource.com/1150682
Cr-Commit-Position: refs/branch-heads/3497@{#86}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/01f811977e700cbafa5cd3087b53cea6940dd23f/ash/host/ash_window_tree_host_platform.cc
[modify] https://crrev.com/01f811977e700cbafa5cd3087b53cea6940dd23f/ash/host/ash_window_tree_host_platform.h
[modify] https://crrev.com/01f811977e700cbafa5cd3087b53cea6940dd23f/ui/aura/window_tree_host.cc
[modify] https://crrev.com/01f811977e700cbafa5cd3087b53cea6940dd23f/ui/aura/window_tree_host.h

This is fixed and merge.

If your system is experiencing this issue, you do not need to go through recovery.

Press Control-Shift-0 to recover, then either downgrade to beta-channel or wait for the next dev-channel release.

Marking this with blocker label as today's CrOS dev was canceled due to this bug.

Control-Shift-0 works. Thanks. Should have thought to try that but I was also interested in timing how long it took to get back up and running. 20 minutes. What windows user wouldn't like to recover from a complete meltdown in 20 minutes. ;-)

Today's update appears to have fixed the issue.

changed status to fixed, so it can be marked as verified
+vaandres to verifed.

Verified the fix using chromebooks and chromebox

Issue 861959 has been merged into this issue.

 Issue 865862  has been merged into this issue.

 Issue 866375  has been merged into this issue.