Is this only happening on a single Chell?

Feedback reports 

https://listnr.corp.google.com/report/75368277244
https://listnr.corp.google.com/report/75762703831
https://listnr.corp.google.com/report/75690463818

Here's the interesting part of powerd.PREVIOUS from the logs in the original report:

[1010/191020:INFO:suspend_delay_controller.cc(62)] Registering suspend delay 58720258 (chrome) of 5000 ms on behalf of :1.11
...
[1010/193014:INFO:state_controller.cc(89)] Dimming screen after 7m
...
[1010/193114:INFO:state_controller.cc(89)] Turning screen off after 8m
...
[1010/193124:INFO:state_controller.cc(89)] Locking screen after 8m10s
...
[1010/193624:INFO:activity_logger.cc(20)] User activity reported
[1010/193624:INFO:state_controller.cc(96)] Undimming screen
[1010/193624:INFO:state_controller.cc(96)] Turning screen on
...
[1010/193625:INFO:daemon.cc(1160)] Got RequestShutdown message from :1.11
...
[1010/193625:INFO:daemon.cc(1570)] Shutting down, reason: user-request
...

----

Five minutes after the screen was turned off and locked, Chrome asked powerd to shut the system down, and it did. Note that Chrome also reported user activity (which usually means input events).

I'm not able to find it now, but I've seen other reports of systems unexpectedly shutting down from the lock screen. I think that the best theory was that the shutdown button is somehow being triggered (maybe via the touchscreen?). If you can repro this on a newer build, there may be more details in the powerd log about why Chrome did this (see  issue 762328 ).

I got the device and I was able to reproduce after
- setting the short powerd timeouts
- five susccessful suspend resume on lock screen
- sixth one got me to the shutdown state - I had the device suspended for ~8 minutes
Same log lines as derat@ pointed out in #3.
Generated logs at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/773421

#6: In the logs that I quoted in #3, the system didn't actually suspend and resume -- the screen was off and locked, but the system hadn't suspended yet. Is that what you meant, or did you additionally wait for the system to suspend?

Can you repro this on other chell devices? What about with a newer OS version?

Aside: this doesn't block the M61 stable release.

My impression was that system have to suspend, so I set the short timeouts.

Looks like it can happen either with or without suspending. Here's powerd.PREVIOUS from #6:

...
[1010/135251:INFO:suspender.cc(473)] Starting suspend
[1010/135251:INFO:main.cc(233)] Running "/usr/bin/powerd_setuid_helper --action=suspend  --suspend_wakeup_count_valid --suspend_wakeup_count=490"
[1010/135259:INFO:daemon.cc(698)] powerd_suspend returned 0
[1010/135259:INFO:suspender.cc(429)] Finishing request 523894785 successfully
[1010/135259:INFO:state_controller.cc(96)] Undimming screen
...
[1010/135259:INFO:state_controller.cc(96)] Turning screen on
...
[1010/135259:INFO:activity_logger.cc(20)] User activity reported
...
[1010/135302:INFO:daemon.cc(1160)] Got RequestShutdown message from :1.11
...
[1010/135302:INFO:daemon.cc(1570)] Shutting down, reason: user-request
[1010/135302:INFO:main.cc(214)] Launching "/usr/bin/powerd_setuid_helper --action=shut_down --shutdown_reason=user-request"
...

---

How is the device being woken here? That seems very relevant. Are you hitting a key (which one?), using the touchpad (motion or clicking?), touching the screen (where?), tapping the power button, etc.?

I pressed the touchpad. It is the deep(er) press that results in this double-like click pushing down. (It seems the device does nothing on single click push)

I see. If you instead hit the Shift key to wake the system, does the touchpad cursor happened to be positioned over the "Shut down" button in the bottom-left corner of the screen?

hah that might be the case, as I remember I was checking this scenario before the failed resume attempt(but it was OK at that time).

I checked again with the mouse pointer over the shut down icon on shelf, and suspended for 5 minutes - device went down after very short interval of screen time on lock-screen.

And the logs is absolutely the same as in #3 and #9

I reproduced, as I pressed relatively slow, which probably generated more than one click on the touchpad, (or as sontis@ suggests, it might be the cklick-up event) leading to the shut-down user action.

But the originating cause is use positioning the mouse pointer over the bottom left corner.

I guess we're still not completely sure that the cursor being over the shut down button is the cause of all of the reports of this that we've seen, but it at least seems plausible.

As far as mitigation goes, maybe we could make Chrome swallow touchscreen and touchpad events while the display is off. Note that we need to make it still report them to powerd as user activity, though (so they'll turn the screen on, if that was the user's intent).

I don't know if we need to handle keyboard events as well. For example, if I lock the screen, hit Tab until "Shut down" is focused, decrease the brightness to 0, and then hit Enter, the system shuts down.

I had this issue several times recently. Nice to see it has bug report here. From my experience, all my cases are "focus on shutdown button when clicking touchpad". It is a bit hard to observe the issue as screen will quickly whiteout and shutdown.

several reports of this on eve as well.  Here's one b/64700962

@warx,jselinger : could you try repro on dev channel where Dan's CL ( https://chromium-review.googlesource.com/c/chromiumos/platform2/+/656060) that logs more info about shutdown is landed?

Dan, should we pull your logging change to R62 as well?

ToT logs present at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/773421/ToT_M63_10020.0.0/ , where the issue was reproduced before the last reboot. 

The repro conditions are:
- lock screen enabled or present
- mouse pointer over Launcher icon in user session, or over Shutdown icon on lock/sign-in screen, and deep click on touchpad(other events like single touchpad tap, or key press do not trigger shut down)
- focus is on Shutdown button on lock/sign-in screen, and multiple Enter key press while screen is dimmed/down(but device not suspended), so one key press takes effect over focused button (resuming the device from suspend seems like eliminating the focus and key press is harmless)

I'm deleting comments about what looks like an unrelated chell graphics issue that leaves the display off after it's turned off for inactivity until suspend/resume. That's tracked at  issue 773825 . Please just use this bug to track cases where the system actually shut down.

#18: Thanks! Here's what powerd got from Chrome:

[1011/100913:INFO:daemon.cc(1163)] Got RequestShutdown message from :1.11 with reason user-request (UI request from ash)

So yeah, it looks like this is just caused by unintentional clicks on the lock screen's "Shut down" button. I can't think of any reasons why this would be a new issue rather than something that's been present during all the time that we've had a shutdown button in the corner of the lock screen.

Over to Albert for possibly finding someone to explore the suggestion in #13. (Maybe there are other approaches that would work here.)

kalin@ we have re-implemented the lockscreen. Could you confirm if this still happens? If so, please assign this back to me.

Asked the reporter to test-reproduce. Update is coming.

Unable to reproduce this issue on ToT 10356.0.0, 66.0.3329.0 chell.

Sounds like this was fixed by the Views-based lock screen.