Introduce ash mojo interface for lock screen action handlers

ash/public/interfaces/tray_action.mojom

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module ash.mojom;
+
+// An action handler state.
+enum TrayActionState {
+  // The client does not support the action.
+  kNotSupported,
+
+  // The client supports the action, but the action cannot be handled at the
+  // moment, for example due to user session not being locked.
+  kNotAvailable,
+  
+  // The client supports the action and is not currently handling the action.
+  kAvailable,
+
+  // The client received the request for the action and it is launching the
+  // flow to handle it.
+  kLaunching,
+
+  // The client is currently handling the action.
+  kActive,
+
+  // The client is currently handling the action, but in background (e.g.
+  // handler window for lock screen action was moved to the background to
+  // surfeace user sign-in UI).

[James Cook, 2017/05/05 02:55:44]

nit: surface

Or rewrite as: "(e.g. the handler window for the lock screen action was moved to
the background and appears underneath the login user pods)"

[tbarzic, 2017/05/05 04:46:26]

Done.

+  kBackground,
+};
+
+// Used by a client (e.g. Chrome) to notify ash of tray action handlers’ 
+// state changes.

[James Cook, 2017/05/05 02:55:44]

nit: I would also say what a tray action is. For example, "Allows a client (e.g.
Chrome) to create a "tray action" button that appears in the status area and
invokes a client/callback method when clicked."

[tbarzic, 2017/05/05 04:46:26]

Done.

+interface TrayAction {

[James Cook, 2017/05/05 02:55:44]

optional: This API is OK for now, but in the long run I wonder if it would be
better to make the API look like:

AddTrayAction(TrayActionState initial_state, TrayActionObserver observer)
or
AddTrayAction(ImageSkia icon, TrayActionObserver observer)
or
AddLockScreenTrayAction(TrayActionObserver observer)

the initial hard-coded version could be something like:

AddLockScreenTrayAction(...)

and

interface TrayActionObserver {
  OnClicked(...modifier keys...);
}

or

interface TrayActionHandler {
  OnEvent(...event...);
}

Functionally it's pretty similar to what you have now, but "SetClient" seems
like a permanent delegate-style thing that you'll set up once and will be used
for a bunch of operations, whereas TrayActionObserver feels more lightweight and
if we added different buttons could be different for each. 

It could even be part of the system_tray.mojom interface.

WDYT?

(BTW, in the future feel free to send me just mojom files or design docs for a
review pass. Apologies for not thinking of this before when I read your doc.)

[tbarzic, 2017/05/05 04:46:26]

Yes, I think this would be a good approach when we have to generalize this,
though I'd wait with going this way until we introduce another action type.

+  // Sets the client to be used to handle action requests.
+  // |lock_screen_note_state|: The current lock screen note action state
+  //     associated with the client.
+  SetClient(TrayActionClient client, TrayActionState lock_screen_note_state);
+
+  // Updates action state for the lock screen note action. If called with no
+  // client set, the state change will not take effect until a client is set.
+  // Null client is equivalent to kNoteSupported state.

[James Cook, 2017/05/05 02:55:44]

kNotSupported

[tbarzic, 2017/05/05 04:46:26]

Done.

+  UpdateLockScreenNoteState(TrayActionState state);
+};
+
+// Used by ash to request Chrome to handle an action.
+interface TrayActionClient {
+  // Requests a lock screen note action to be handled.
+  RequestNewLockScreenNote();
+};