[WebPayments] Implement state transitions in desktop WebPayments dialog.

chrome/browser/ui/views/payments/payment_dialog_state.h

Index: chrome/browser/ui/views/payments/payment_dialog_state.h
diff --git a/chrome/browser/ui/views/payments/payment_dialog_state.h b/chrome/browser/ui/views/payments/payment_dialog_state.h
new file mode 100644
index 0000000000000000000000000000000000000000..76a688b528757446304da1febd190810a5a1c3b4
--- /dev/null
+++ b/chrome/browser/ui/views/payments/payment_dialog_state.h
@@ -0,0 +1,55 @@
+// Copyright 2016 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.
+
+#ifndef CHROME_BROWSER_UI_VIEWS_PAYMENTS_PAYMENT_DIALOG_STATE_H_
+#define CHROME_BROWSER_UI_VIEWS_PAYMENTS_PAYMENT_DIALOG_STATE_H_
+
+#include <memory>
+
+#include "base/macros.h"
+
+namespace views {
+class View;
+}
+
+namespace payments {
+
+// Base class for the different WebPayments UI states.
+class PaymentDialogState {
+ public:
+  PaymentDialogState();
+  ~PaymentDialogState();
+
+  // Create the view associated with this state if needed and return it. This
+  // object owns the view and has called set_owned_by_client() on it.
+  views::View* GetView();
+
+  // Marks the state as interactable or not depending on |interactable|. States

[sky, 2016/12/08 03:58:17]

This seems error prone, and a very weird interface that you allow the user to
interact with ui elements but have them do nothing. Did you consider changing
the enabled state of the views? Assuming you don't want to do that, having each
view know to correctly deal with this is error prone. I recommend having a
parent view that you can toggle CanProcessEventsWithinSubtree() when you don't
want the user to interact with it.

[anthonyvd, 2016/12/08 20:31:22]

I didn't know about CanProcessEventsWithinSubtree(), this is much better!

Done.

+  // should be marked as non-interactable when they are being transitioned out
+  // or have another state being transitioned in on top of them. A non-
+  // interactable state shouldn't trigger events at all. This is to prevent non-
+  // foreground states from being interacted with.
+  void SetInteractable(bool interactable) {
+    interactable_ = interactable;
+  }
+
+  bool interactable() { return interactable_; }
+
+ protected:
+  // Create the view associated with this state. Subclasses should override this
+  // to create the view they represent. This is called by GetView(), which calls
+  // set_owned_by_client() so CreateView() doesn't have to do anything about the
+  // ownership of the return view.
+  virtual views::View* CreateView() = 0;
+
+ private:
+  bool interactable_;
+  std::unique_ptr<views::View> view_;
+
+  DISALLOW_COPY_AND_ASSIGN(PaymentDialogState);
+};
+
+}  // namespace payments
+
+#endif  // CHROME_BROWSER_UI_VIEWS_PAYMENTS_PAYMENT_DIALOG_STATE_H_