Support "learn more" link for EME in PermissionRequestManager code-path on Android

chrome/browser/ui/permission_bubble/mock_permission_prompt.cc

Index: chrome/browser/ui/permission_bubble/mock_permission_prompt.cc
diff --git a/chrome/browser/ui/permission_bubble/mock_permission_prompt.cc b/chrome/browser/ui/permission_bubble/mock_permission_prompt.cc
index 2618143e41f8bf3b7f10a5e75ccce78ab04c2a2e..36e09665c1974cb58b3c52099d8d3fa0fcf5a553 100644
--- a/chrome/browser/ui/permission_bubble/mock_permission_prompt.cc
+++ b/chrome/browser/ui/permission_bubble/mock_permission_prompt.cc
@@ -20,6 +20,12 @@ void MockPermissionPrompt::Show() {
   for (const PermissionRequest* request : manager_->requests_) {
     factory_->request_types_seen_.push_back(
         request->GetPermissionRequestType());
+    // The actual prompt will call these, ensure we have test coverage.

[Timothy Loh, 2017/06/06 03:46:36]

Not sure if I should add an instrumentation test for EME or just do this. This
is simpler and adds coverage for other request types compared to a test for EME
so I preferred it.

[raymes, 2017/06/06 05:14:18]

I would rather check that the results are meaningful in some way. e.g. either by
storing the results in a member variable and comparing them in the test harness,
or just EXPECT'ing here that they are non-null.

[Timothy Loh, 2017/06/06 09:29:15]

Not sure this is really an appropriate place to have EXPECTs, but I added some.
WDYT?

[raymes, 2017/06/06 22:53:33]

It's definitely not ideal but I think it's slightly preferable to just calling
the functions. I consider this as part of the test infrastructure.

+    request->GetIconId();
+    request->GetMessageTextFragment();
+#if defined(OS_ANDROID)
+    request->GetMessageText();
+#endif
   }
   factory_->UpdateResponseType();
   is_visible_ = true;