Autofill: Replace "save credit card" infobar with a bubble (Views only).

components/autofill/core/browser/ui/save_card_bubble_controller.h

Index: components/autofill/core/browser/ui/save_card_bubble_controller.h
diff --git a/components/autofill/core/browser/ui/save_card_bubble_controller.h b/components/autofill/core/browser/ui/save_card_bubble_controller.h
new file mode 100644
index 0000000000000000000000000000000000000000..6aeb69ab2cba1501bf699948b8f48bd67d6ed8a8
--- /dev/null
+++ b/components/autofill/core/browser/ui/save_card_bubble_controller.h
@@ -0,0 +1,48 @@
+// Copyright 2015 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 COMPONENTS_AUTOFILL_CORE_BROWSER_UI_SAVE_CARD_BUBBLE_CONTROLLER_H_
+#define COMPONENTS_AUTOFILL_CORE_BROWSER_UI_SAVE_CARD_BUBBLE_CONTROLLER_H_

[Evan Stade, 2015/10/16 01:20:44]

I don't think this belongs in components as it won't be used by ios

[Justin Donnelly, 2015/10/19 17:39:08]

It won't? Do you mean the save card UI would have a different interface or that
there won't be a save card UI on iOS? I don't think either of those are true but
I could be missing something.

[bondd, 2015/10/22 02:15:17]

Yes, it seems to me we will use this class on iOS. Don't we do a similar thing
for the CardUnmaskPrompt on iOS?

[Justin Donnelly, 2015/10/23 13:53:09]

Evan, you never answered this question. I'm pretty sure I'm going to be moving
this and save_card_bubble_view.h right back to components as soon as we
implement upload on iOS. But again, I may be missing something, so I'm hoping
you can clarify what you have in mind.

[Evan Stade, 2015/10/23 17:36:14]

ios plans to have a bubble? Does ios Chrome have the concept of a bubble or an
icon in the location bar?

It's easier to see in more recent patchsets, but this "controller" interface is
really really thin, so we're not even gaining anything by sharing it. It's
basically just some thunks for passing through to the model, and is tightly
coupled with the presentation (a bubble). I don't see anything substantive that
could/should be shared with ios here. That said, you'll have the opportunity to
refactor later if it does make sense. But I'd rather have the code make sense
relative to the present than make sense relative to a hypothetical future world.

[Justin Donnelly, 2015/10/23 17:41:09]

Fair enough.
It'll be an infobar, not a bubble. I suppose that strengthens your argument,
since a common interface would probably need to be renamed from "Bubble" to
"Prompt" or somesuch.

+
+#include "base/callback.h"
+
+namespace autofill {
+
+class SaveCardBubbleView;
+
+// Interface for per-tab class to control the save credit card bubble and
+// Omnibox icon.
+class SaveCardBubbleController {

[Evan Stade, 2015/10/16 01:20:44]

only the methods visible/used by the view should be in this interface. Other
stuff can be moved to public on the impl class.

[bondd, 2015/10/22 02:15:17]

Done.

+ public:
+  // |save_card_callback| will be invoked if/when the Save button is pressed.
+  virtual void CreateBubble(const base::Closure& save_card_callback) = 0;
+
+  // CreateBubble() must be called first.
+  virtual void ShowBubble() = 0;
+
+  // Functions called by SaveCardBubbleView.
+  virtual void OnSaveButton() = 0;
+  virtual void OnCancelButton() = 0;
+  virtual void OnBubbleClosed() = 0;
+
+  // Returns true if Omnibox save credit card icon should be visible.
+  virtual bool IsIconVisible() const = 0;
+
+  // Returns true if Omnibox save credit card should be shown in its "toggled
+  // on" state.
+  virtual bool IsIconToggled() const = 0;
+
+  // Returns nullptr if no bubble is currently shown.
+  virtual SaveCardBubbleView* save_card_bubble_view() const = 0;
+
+ protected:
+  SaveCardBubbleController() {}
+  virtual ~SaveCardBubbleController() {}
+
+  DISALLOW_COPY_AND_ASSIGN(SaveCardBubbleController);
+};
+
+}  // namespace autofill
+
+#endif  // COMPONENTS_AUTOFILL_CORE_BROWSER_UI_SAVE_CARD_BUBBLE_CONTROLLER_H_