Can you add some more explanation? Are you expecting Windows to lock the Windows desktop or for Chrome OS to lock the Chrome OS desktop?

file:///var/log/power_manager/powerd.LATEST has information about what the Chrome OS power manager is doing. If the inactivity timer is being reset, you'll see why there. https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/docs/logging.md has more information about interpreting these logs. If you attach the log file (and mention the time at which the unexpected behavior occurred), Todd or I can probably take a look.

The described behavior seems surprising to me, since if the monitor being turned off were being misinterpreted as user activity, powerd likely would've turned the screen back on immediately at that point.

Is the behavior encountered by Citrix actually tied to the differences between battery and AC power documented here that might have been perceived as a chromebook vs chromebox issue?

https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/docs/inactivity_delays.md

Note, the total difference in delay is 6 mins, which matches the testing results from Citrix.

[Citrix]: We are expecting WIndows to lock the windows desktop running on chromebox after 10 mins of user inactivity. While on chromebook it works as expected. I have attached the power logs for both devices as asked in comment1 

Deleted: power_logs_chromebook.txt 10.1 KB

power_logs_chromebook.txt 10.1 KB View Download

Deleted: power_logs_chromebox.txt 14.3 KB

power_logs_chromebox.txt 14.3 KB View Download

I don't know anything about how Windows screen-locking works, and it seems unlikely that Chrome OS power management has much to do with this. My best guess is that the display being turned off might be triggering a synthetic mouse motion event that Windows treats as user activity... but that's just a guess, and I don't know enough about Windows to know how to prove or disprove it.

Exact behavior when a display gets turne off due to inactivity depends on display, how it's connected.

I think Dan's guss isn't far fetched, but we need more information to investigate. Can you file a feedback report first?

It'd also be useful if you can test with different type of monitors and see if you get the same issue.

Some forum posts from windows side,

https://social.technet.microsoft.com/Forums/windows/en-US/8a9b5aa7-fe33-4e6d-b39b-8ac80a21fdc2/disable-monitor-off-detection-how?forum=w7itprogeneral
https://answers.microsoft.com/en-us/windows/forum/windows_10-power/monitor-off-detection-moving-windows-to-turned-off/58f3d247-b0bf-4990-8627-fb15a94c5167

that at least 'monitor off detection' is mentioned as a feature on windows.

chromebox:
----------
[0110/082719:INFO:state_controller.cc(944)] Updated settings: dim=7m screen_off=7m30s lock=0s idle_warn=0s idle=8m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 wake_locks=system
...
[0110/083629:INFO:state_controller.cc(104)] Dimming screen after 7m
...
[0110/083735:INFO:state_controller.cc(104)] Turning screen off after 7m30s
...
[0110/083825:INFO:activity_logger.cc(20)] User activity reported
...
[0110/083825:INFO:state_controller.cc(944)] Updated settings: dim=14m screen_off=14m30s lock=0s idle_warn=0s idle=15m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 wake_locks=system
[0110/083825:INFO:state_controller.cc(111)] Undimming screen
...
[0110/083838:INFO:daemon.cc(972)] Got RequestShutdown message from :1.9 with reason user-request (UI request from ash: power button)

So above state transitions is what I'd expect but as mentioned by others not sure where windows would take its user events from.  Also if my math is correct it looks like it wasn't 10min ...

  0110/083629:INFO:state_controller.cc(104)] Dimming screen after 7m

would equate to 08:29:29 however activity was seen at 08:38:25 
  
  0110/083825:INFO:activity_logger.cc(20)] User activity reported

chromebook:
-----------
its only ~30secs long so likely not the right log file.

Along w/ feedback reports are there any logs on the citrix / windows side you can include that expose user events there?

Also would be good to document the repro in more detail and if possible share the test build w/ developers here to attempt to re-create.

with respect to RVG label have confirmed it was not intentional and while its been added auto-magically ( https://groups.google.com/a/google.com/forum/#!msg/monorail-eng/69Kj7hSt0ls/XQQqwaflDwAJ perhaps) no one on this thread can remove it ATM nor was it intended.  Adding 'allpublic' label as WA.

I wonder if we're emitting CancelModeEvent when locking the screen, which then trigger user activity logger?

https://cs.chromium.org/chromium/src/ash/wm/lock_state_controller.cc?rcl=4bfafb0ee4eeacf365ac7e0b9fb23cec89739e03&l=365

I'm not familiar with this, but derat@ may know.

Huh. No, I'm not familiar with ET_CANCEL_MODE either (I'm on the blame list for that line of code, but I suspect it was just a refactoring). Based on the description, your theory sounds plausible, though:

  // Sent by the system to indicate any modal type operations, such as drag and
  // drop or menus, should stop.
  ET_CANCEL_MODE,

I don't think that these events are treated as user activity by Chrome OS (i.e. Chrome doesn't forward them to powerd), but I could believe that they're disrupting power management on the Windows side if they make it through to there. Maybe Scott or Ben knows more.