Repro video and debug logs here: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/767680/

Reproduced on previous RC 9765.63.0, 61.0.3163.90 as well. Changing RBB to RBS.

Issue also seen on other auron board lulu.

Not reprod on EVE. reprod only on Samus and Lulu.

abodenha@ can you please take a look at this RBS? who should be the owner for this?

Lock screen seems to still work, looks like a rendering bug. The UI would flicker a bit as well, see screenshot.

Only happens when an Android app is running.

Deleted: Screenshot 2017-09-25 at 4.06.11 PM.png 921 KB

	Screenshot 2017-09-25 at 4.06.11 PM.png 921 KB View Download

marcheu@ this is an M61 stable blocker. Can you please take a look?

I suspect this is a duplicate of  issue 764584 .

 Issue 764584  has been merged into this issue.

 Issue 758820  has been merged into this issue.

Looks like UI tiles are not being initialized properly. Any error messages at the bottom of chrome://gpu? Does changing "GPU rasterization" to force enabled on all layers in about:flags make a difference?

Attached chrome://gpu. Issue repro'd even after changing "GPU rasterization" to force enabled on all layers

Deleted: chrome___gpu.pdf 77.9 KB

chrome___gpu.pdf 77.9 KB Download

 Issue 770842  has been merged into this issue.

This seems like a UI bug. Albert can you triage?

jdufault@ was pretty convinced everything in the lock screen was still working but not rendering. The trick is figuring out what layer of things is running off the rails.

Bouncing back to jdufault@. Can you put heads together tomorrow with marcheu@ and reveman@ and see what the 3 of you can figure out?

FWIW neither zelidrag@ nor I are able to repro, so I think removing RBS is the right move here.

Re #6, I have seen missing user pods without an Android app running. See  issue 764584 .

What did the artifacts look like when forcing GPU rasterization? The tile size should have changed from that. Can you enable tile borders in about:flags to verify that these artifacts align with tile borders?

+xdai

This might be related to the screen freeze issue we saw yesterday. I could not find the bug on daisy's plate but suspect they are dups.

We should confirm once a fix is in place for that one.

Re#20: The screen freeze issue is  Issue 769570 . The culprit CL has been identified. The CL was landed in M63 so might not be the reason to cause the issue here. But it's interesting that the two issues are both repro'ed by pressing the power button. 

I had two instances over the weekend where opening the lid on my samus took me to a lock screen without a pod. 61.0.3163.117 9765.79.0 (Official Build) beta-channel samus

Not sure if it's the same as this issue or not.

Sadly, I'm an idiot and neglected to file feedback when it happened.

Deleted: IMG_20171006_195130.jpg 3.2 MB

	IMG_20171006_195130.jpg 3.2 MB View Download

Any update on this? We are planning a stable RC next week and this bug is marked as a blocker.

I'm unable to reproduce on the latest beta build (62.0.3202.55 9901.46.0). Lock seems to work correctly both with and without arc enabled and play store running.

This feels more like a graphics problem than a login problem, and 
there have been a large number of graphics issues lately, so I suspect this got fixed as a result of those being fixed. Unless there is a more recent repro/logs I don't think there is much actionable at the moment, so I'm removing RBS.

This may be related to  crbug.com/772586 . 

I just reproduced missing lock screen UI on:


Google Chrome	62.0.3202.63 (Official Build) beta (64-bit)
Revision	0
Platform	9901.49.0 (Official Build) beta-channel samus

It was from a suspend/resume overnight.

Logs from my current session (though I logged out and in to get the UI back): https://drive.google.com/a/google.com/file/d/1l-E0d9uokAxQ-OHaFj9UkKmy0uY3fx9h/view?usp=sharing

Re #29: Could you grab chrome user level logs and attach it here? It seems the problem is with the lock from 2017-10-23T18:29:33 to 2017-10-24T08:59:52. So the chrome user log include that time range would be interesting. The device seems not signed out for a long time. The user log with the time range could be the one started on 10/10.

This looks like the problematic lock:

2017-10-23T18:29:33.890652-07:00 INFO session_manager[1282]: [INFO:session_manager_impl.cc(805)] LockScreen() method called.
... vblank wait timed out, kernel stack dump ...
2017-10-23T18:29:34.247090-07:00 INFO session_manager[1282]: [INFO:session_manager_impl.cc(810)] HandleLockScreenShown() method called.
...
2017-10-24T08:59:04.386007-07:00 DEBUG kernel: [ 5584.166392] PM: Finishing wakeup.
...
2017-10-24T08:59:52.524276-07:00 INFO session_manager[1282]: [INFO:browser_job.cc(157)] Terminating process: 
...
No unlock afterwards. User signed out.

<triage> Cannot reproduce on 72.0.3593.0, please reopen if seen again. </triage>