FWIW I saw something similar once on a recent ToT build on samus. I was not using Tether but I was working on the Settings UI (but the whole browser became unresponsive so it doesn't seem like it could be Web UI related).

An in-progress build+deploy restarted the device before I could do any debugging.

I just updated my chrome repro. If I see it again I will try to investigate.

This isn't a gardener issue per-se, we should leave it untriaged for proper assignment.

Wow there is a lot of bluetooth error spam in that log. Not sure if that's related but it's certainly a problem.

Unfortunately I had to re-image my machine after I saw that bug so I can't tell if I had the same error spam when I saw this.

I was looking into some Bluetooth issues while I repro'ed this issue, but I doubt it is caused *by* Bluetooth. No amount of Bluetooth errors should be able to freeze the UI.

Well, there are some bluetooth related dbus errors at the end of the log that are of specific concern; we have seen blocking dbus calls lock up the UI before (although not in a very long time).

zork@ can someone on your team drive this until we know more?

Daisy, could you dig into this?

This just happened on my device with a build from today (63.0.3228.0)

I was in the login screen and the UI was completely unresponsive. However, when I connected a second display, I was logged in and the UI on that display worked. (I -think- that I probably typed in my passphrase and hit enter in the login screen and it just never transitioned).

This seems like a pretty strong indicator that this is related to the new lock screen UI.

Also, I was able to use ctrl-shift-q to log out, at which point my UI responded normally.

I've never reproduced this issue at the login screen; every time it's happened to me, I've been logged in already. I'm not sure about your assertion that it is due to the new lock screen UI, though it might be possible due to some subtle interaction.

I've been seeing this a bit myself, it happens on both views and webui lock screen across a variety of devices. It seems to happen most often after resume so I suspect a display/input bug.

A display bug would be consistemt with my observations in comment #8 where the second display when attached was functional. I did play with mirroring and unified desktop but was unable to get the primary display to work, so it seems like it might be a relatively low level bug.

+oshima@

The only logs that I found might be related to display in comment#0 (it repeated several times with different power_state which might related to resume/suspend the device):
[4277:4277:0927/182233.931339:VERBOSE1:display_configurator.cc(869)] SetDisplayPower: power_state=ALL_ON flags=0, configure timer=Stopped
[4277:4277:0927/182233.937547:VERBOSE1:display_configurator.cc(917)] Display snapshots invalidated.
[4277:4277:0927/182233.937609:VERBOSE1:update_display_configuration_task.cc(69)] OnDisplaysUpdated: new_display_state=SINGLE new_power_state=ALL_ON flags=0 force_configure=0 display_count=1
[4277:4277:0927/182233.937651:VERBOSE1:display_configurator.cc(212)] EnterState: display=SINGLE power=ALL_ON

+kylechar@ who did a lot of cleanup work in display recently for ideas.

We always log display configuration events, so you would expect to see log messages similar to that on startup, on suspend/resume, connecting a second monitor, etc. The logged events look perfectly normal to me, one display is connected and powered on with no pending display configuration.

FYI: I'm seeing this issue very often now, usually multiple times per day.

I've managed to repro it and started bisecting...

Bisect is done. Found the culprit CL: https://chromium-review.googlesource.com/c/chromium/src/+/680476
Assign to the CL's owner for further investigation.

Repro steps: use the power button to turn off the screen, wait a few seconds, use the power button to turn on the screen. The Cros UI then becomes totally frozen, only the mouse can still be moved around. It can be repro'ed in login screen or inside a user session.

 Issue 772018  has been merged into this issue.

+gkihumba (M63 TPM)

IMHO this is serious enough that I wouldn't even want to push a dev-channel image.

@#24: Should we revert crrev.com/c/680476 ? We also merged it to 62, so in case we decide to revert, I'll revert that one too.

Reverted the two patches while we work on another fix for crbug.com/763736

Marking this as fixed.

For reference, revert is here: https://chromium-review.googlesource.com/c/chromium/src/+/705494

Landed in Chrome 63.0.3235.0 (not yet in Chrome OS)

Which Chrome OS can we expect this fix?

The fix (revert) made it to 63.0.3236.0.

 Issue 772088  has been merged into this issue.

It looks like this was just merged into 62 at https://chromium-review.googlesource.com/#/c/chromium/src/+/705975/ ?

If so we should be good on the next beta, I will generate a new Chrome revision to ensure we get this in tonight.

Verified on M63 (10025.0.0, 63.0.3236.0) and M62 (9901.46.0, 62.0.3202.55)

khorimoto, in comment #0
> Chrome Version: 63.0.3223.0
> OS: CrOS 9981.0.0, on Eve

These versions can't be right since "Disable overlays on HDC::Disable" was in 3224 but not in 3223
https://chromium.googlesource.com/chromium/src/+log/63.0.3223.0..63.0.3224.0?n=10000

See other reproduction steps, ERROR messages and version information in duplicate (to be?)  issue 774304 . There we found 3223 to be the last working version.

The revert: https://chromium.googlesource.com/chromium/src/+log/63.0.3234.0..63.0.3235.0?n=10000

I started seeing this issue again on ToT.

Daniel, when do you think we can get a fix for this?

Actually, I think this was actually due to a local change. Sorry for the noise.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-63; 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-63 label, otherwise remove Merge-TBD label. Thanks.