#2 may also be an issue but I'm not sure.
Customer has already engaged Citrix regarding this behavior.
Should we ask customer for test credentials for Citrix Workspace to reproduce the issue?

Dear team,

Could someone help with the triage of this bug?
One of our top Enterprise customers is asking for some updates on this issue.

Thank you in advance.

[ADDITIONAL INFORMATION]

Customer has been informed by Citrix team that they have implemented a new version of the affected app that will have the ability to manage the power settings 
(They are testing the new version (in beta for the time being) and it seems that it works fine). 

However, they need to understand why the previous version was working as intended in one OU  but not anymore after being moved to a different OU,
even if the settings were the same as well as the app version. 

I'm unable to interpret logs without seeing a timeline of when unexpected behavior was observed.

I also suspect that no one at Google knows exactly what the Citrix app is doing. Can you add someone from Citrix to this bug to provide context about what their code is calling (the chrome.power API?) and when?

I think that "Allow app to manage power" configures very short inactivity delays, with the expectation that the kiosk app will use chrome.power.requestKeepAwake to prevent the system from suspending most of the time. The behavior that you describe in the third case might imply that the app isn't calling requestKeepAwake properly. But I'm just guessing.

@derat: 

Regarding the "timeline" there is a readme.txt in the zip with a lot of information. 
I hope this helps.

#7: Thanks for pointing that out. Someone from Citrix still needs to describe their app's behavior (in terms of the chrome.power API), though.

Citrix Comment:
Following are our observations with respect to 'Allow app to manage power' in kiosk :

When ‘Allow app to manage power’ is enabled
1)	If kiosk app is not calling chrome.power api, the screen goes off ~2 secs but it keeps the system active in background.
2)	If kiosk app calls chrome.power.requestKeepAwake(“display”), screen doesn’t go off and system also remains active, which is the expected behavior.
3)	 If kiosk app calls chrome.power.requestKeepAwake(“system”), screen  goes off and keeps the system active. (Same as 1). Not sure if this is intended behavior.

 When ‘Allow app to manage power’ is disabled
1)	If kiosk app calls chrome.power.requestKeepAwake(“display”), screen doesn’t go off and system also remains active. So app is still able to use chrom.power api, which is not expected.
2)	 If kiosk app calls chrome.power.requestKeepAwake(“system”), screen  goes off in ~ 6 minutes and keeps the system active. So app is still able to use chrom.power api, which is not expected.

Based on policy description at https://support.google.com/chrome/a/answer/6177447?hl=en, it should not allow us to call chrome.power API, if “Allow app to manage power” is not enabled. But it is allows as observed by us.

#10: That documentation is misleading, unfortunately. Here's what I wrote in a recent email thread:

---

The chrome.power API predates the "Allow app to manage power" policy and behaves the same regardless of whether or not the policy is set: while a keep-awake request is held, power management is inhibited.

The policy sets a very short idle timeout to essentially give the app the ability to manage the system's state almost in real time by using chrome.power to hold or release keep-awake requests.

The document at http://go/powerd/docs/inactivity_delays.md may be helpful if you haven't already seen it.

---

This would be a more accurate description of the policy: "Sets power management inactivity delays to very short intervals. The app must call chrome.power.requestKeepAwake (https://developer.chrome.com/apps/power) immediately after being launched and can then call chrome.power.releaseKeepAwake when it wants the system to go to sleep."

---

As I understand it (but someone who works on enterprise should confirm), the policy just sets short inactivity delays after the app has been started. If I'm remembering correctly, the intent was to give apps a way to suspend the system (almost) immediately using the existing chrome.power functionality.

If you don't enable the policy, the delay between calling chrome.power.releaseKeepAwake and the system turning its display off or suspending is much longer (the same as on a normal non-kiosk Chrome OS system), on the order of minutes rather than seconds. Without the policy, there's no way to make the system go to sleep quickly.