[Payments] Record CanMakePayment metrics on Desktop.

components/payments/content/payment_request.cc

 // 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.
 
 #include "components/payments/content/payment_request.h"
 
 #include <string>
 #include <utility>
 
 #include "base/memory/ptr_util.h"
 #include "components/payments/content/origin_security_checker.h"
 #include "components/payments/content/payment_details_validation.h"
 #include "components/payments/content/payment_request_web_contents_manager.h"
 #include "content/public/browser/browser_thread.h"
 #include "content/public/browser/web_contents.h"
 
 namespace payments {
 
 PaymentRequest::PaymentRequest(
     content::WebContents* web_contents,
     std::unique_ptr<PaymentRequestDelegate> delegate,
     PaymentRequestWebContentsManager* manager,
     mojo::InterfaceRequest<mojom::PaymentRequest> request,
     ObserverForTest* observer_for_testing)
     : web_contents_(web_contents),
       delegate_(std::move(delegate)),
       manager_(manager),
       binding_(this, std::move(request)),
-      observer_for_testing_(observer_for_testing) {
+      observer_for_testing_(observer_for_testing),
+      journey_logger_(delegate_->IsIncognito(),
+                      web_contents_->GetLastCommittedURL(),
+                      delegate_->GetUkmService()) {
   // OnConnectionTerminated will be called when the Mojo pipe is closed. This
   // will happen as a result of many renderer-side events (both successful and
   // erroneous in nature).
   // TODO(crbug.com/683636): Investigate using
   // set_connection_error_with_reason_handler with Binding::CloseWithReason.
   binding_.set_connection_error_handler(base::Bind(
       &PaymentRequest::OnConnectionTerminated, base::Unretained(this)));
 }
 
 PaymentRequest::~PaymentRequest() {}
@@ skipping 57 matching lines @@
   }
 
   if (!state_->AreRequestedMethodsSupported()) {
     client_->OnError(mojom::PaymentErrorReason::NOT_SUPPORTED);
     if (observer_for_testing_)
       observer_for_testing_->OnNotSupportedError();
     OnConnectionTerminated();
     return;
   }
 
+  journey_logger_.SetShowCalled();
   delegate_->ShowDialog(this);
 }
 
 void PaymentRequest::UpdateWith(mojom::PaymentDetailsPtr details) {
   std::string error;
   if (!validatePaymentDetails(details, &error)) {
     LOG(ERROR) << error;
     OnConnectionTerminated();
     return;
   }
   spec_->UpdateWith(std::move(details));
 }
 
 void PaymentRequest::Abort() {
   // The API user has decided to abort. We return a successful abort message to
   // the renderer, which closes the Mojo message pipe, which triggers
   // PaymentRequest::OnConnectionTerminated, which destroys this object.
+  // TODO(crbug.com/716546): Add a merchant abort metric,
+  journey_logger_.RecordJourneyStatsHistograms(
+      JourneyLogger::COMPLETION_STATUS_OTHER_ABORTED);
   if (client_.is_bound())
     client_->OnAbort(true /* aborted_successfully */);
 }
 
 void PaymentRequest::Complete(mojom::PaymentComplete result) {
   if (!client_.is_bound())
     return;
 
   if (result != mojom::PaymentComplete::SUCCESS) {
     delegate_->ShowErrorMessage();
   } else {
+    journey_logger_.RecordJourneyStatsHistograms(
+        JourneyLogger::COMPLETION_STATUS_COMPLETED);
     // When the renderer closes the connection,
     // PaymentRequest::OnConnectionTerminated will be called.
     client_->OnComplete();
   }
 }
 
 void PaymentRequest::CanMakePayment() {
   // TODO(crbug.com/704676): Implement a quota policy for this method.
   // PaymentRequest.canMakePayments() never returns false in incognito mode.
   client_->OnCanMakePayment(
       delegate_->IsIncognito() || state()->CanMakePayment()
           ? mojom::CanMakePaymentQueryResult::CAN_MAKE_PAYMENT
           : mojom::CanMakePaymentQueryResult::CANNOT_MAKE_PAYMENT);
+  journey_logger_.SetCanMakePaymentValue(state()->CanMakePayment());

[Mathieu, 2017/05/02 20:56:47]

I think we should log the value that is sent back to the merchant, which takes
into account the incognito state. What do you think?

[sebsg, 2017/05/02 22:15:08]

Right, it's more safe if the code changes, but we currently don't log
CanMakePayment metrics if the user is in incognito, so the behavior is the same.
Thanks for checking :)

   if (observer_for_testing_)
     observer_for_testing_->OnCanMakePaymentCalled();
 }
 
 void PaymentRequest::OnPaymentResponseAvailable(
     mojom::PaymentResponsePtr response) {
   client_->OnPaymentResponse(std::move(response));
 }
 
 void PaymentRequest::OnShippingOptionIdSelected(
     std::string shipping_option_id) {
   client_->OnShippingOptionChange(shipping_option_id);
 }
 
 void PaymentRequest::OnShippingAddressSelected(
     mojom::PaymentAddressPtr address) {
   client_->OnShippingAddressChange(std::move(address));
 }
 
 void PaymentRequest::UserCancelled() {
   // If |client_| is not bound, then the object is already being destroyed as
   // a result of a renderer event.
   if (!client_.is_bound())
     return;
 
+  journey_logger_.RecordJourneyStatsHistograms(
+      JourneyLogger::COMPLETION_STATUS_USER_ABORTED);
+
   // This sends an error to the renderer, which informs the API user.
   client_->OnError(mojom::PaymentErrorReason::USER_CANCEL);
 
   // We close all bindings and ask to be destroyed.
   client_.reset();
   binding_.Close();
   manager_->DestroyRequest(this);
 }
 
 void PaymentRequest::OnConnectionTerminated() {
   // We are here because of a browser-side error, or likely as a result of the
   // connection_error_handler on |binding_|, which can mean that the renderer
   // has decided to close the pipe for various reasons (see all uses of
   // PaymentRequest::clearResolversAndCloseMojoConnection() in Blink). We close
   // the binding and the dialog, and ask to be deleted.
+  journey_logger_.RecordJourneyStatsHistograms(
+      JourneyLogger::COMPLETION_STATUS_OTHER_ABORTED);

[Mathieu, 2017/05/02 20:56:47]

This method can get called because of many reasons, some of them positive (for
example, as a result of line 146). Therefore, I don't think this call is right.
Let me know if you need more details about when this might be called. 

[sebsg, 2017/05/02 22:15:08]

Yeah I would like if you could give me more info. I'm not sure I understand what
can be a positive reason that is not a payment completion. Thanks!

[Mathieu, 2017/05/03 02:22:49]

Line 33-37 gives a possible way we could know of the reason. But we can't always
assume it's an abort. I would remove this logging statement. It feels wrong
especially since on line 142 we log a different completion status, and we will
still end up on this line. 

[sebsg, 2017/05/03 17:10:11]

Thanks, will look at this right after this CL

   client_.reset();
   binding_.Close();
   delegate_->CloseDialog();
   manager_->DestroyRequest(this);
 }
 
 void PaymentRequest::Pay() {
   state_->GeneratePaymentResponse();
 }
 
 }  // namespace payments