Add a row in the network tray to inform users to turn Bluetooth on to enable Tether.

ash/system/tray/tray_details_view.h

Index: ash/system/tray/tray_details_view.h
diff --git a/ash/system/tray/tray_details_view.h b/ash/system/tray/tray_details_view.h
index f046fcdcdeec65b9c5ef0b51d7c26a5ff1a25161..15be1243860732064b7883cced404bcaf13341f0 100644
--- a/ash/system/tray/tray_details_view.h
+++ b/ash/system/tray/tray_details_view.h
@@ -8,6 +8,7 @@
 #include <memory>
 
 #include "ash/ash_export.h"
+#include "ash/system/tray/actionable_view.h"
 #include "ash/system/tray/tray_constants.h"
 #include "ash/system/tray/view_click_listener.h"
 #include "base/macros.h"
@@ -58,16 +59,26 @@ class ASH_EXPORT TrayDetailsView : public views::View,
   // A view containing only a label, which is to be inserted as a non-targetable
   // row within a system menu detailed view (e.g., the "Scanning for devices..."
   // message that can appear at the top of the Bluetooth detailed view).

[tdanderson, 2017/06/27 19:33:21]

By making InfoLabel an ActionableView, you would be making all InfoLabel
instances inherit the 'clickable row' behaviors below, which are not desirable
to have for the non-clickable InfoRow instances, e.g., the info row that
displays the IDS_ASH_STATUS_TRAY_INITIALIZING_CELLULAR string:

* When clicked or tapped, the row will show an 'ink drop ripple'.

* When highlighting using ChromeVox spoken feedback, the row will be reported as
a "Button" when it isn't (see ActionableView::GetAccessibleNodeData()). As a
side note, it's a good practice to test your code with ChromeVox to make sure
a11y users are getting the correct experience - you can activate this from a11y
settings.

In other words, please look into an alternate design where all existing
InfoLabels do not change in behavior. (It's worth double-checking that what I
said above is correct too.)

[Kyle Horimoto, 2017/06/27 20:37:10]

Good point. Would you suggest creating a specific view type deriving from
ActionableView and using it only for this specific status message?

[tdanderson, 2017/06/27 21:27:39]

I'll leave it to Leslie to investigate possible approaches here, but an
off-the-top-of-my-head idea would be to maybe have two concrete classes (one
extending View and the other extending ActionableView), perhaps with a common
interface. There would need to be some massaging of the logic in NetworkListView
with respect to how it instantiates/points to these objects.

-  class InfoLabel : public View {
+  class InfoLabel : public ActionableView {
    public:
     explicit InfoLabel(int message_id);
-    ~InfoLabel() override;
+    void Update(int message_id);

[Kyle Horimoto, 2017/06/27 19:36:57]

Please add documentation to explain what Update() does that SetMessage() doesn't
do.

 
-    void SetMessage(int message_id);
+    enum Action { NONE, OPEN_BLUETOOTH_SETTINGS };
+
+   protected:
+    // ActionableView

[tdanderson, 2017/06/27 19:33:21]

nit: ':' at end of 'ActionableView'

[Kyle Horimoto, 2017/06/27 19:36:57]

Colon at the end of the line:

// ActionableView:

+    bool PerformAction(const ui::Event& event) override;
 
    private:
+    void SetAction(int message_id);
+    void SetStyle();
+    void SetMessage(int message_id);
+
     views::Label* const label_;
 
+    Action action_;
+
     DISALLOW_COPY_AND_ASSIGN(InfoLabel);
   };