Enable keyboard navigation for Desktopcapture window selection dialog

chrome/browser/ui/views/desktop_media_picker_views_unittest.cc

 // Copyright 2014 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 "base/bind.h"
 #include "base/run_loop.h"
 #include "base/strings/utf_string_conversions.h"
 #include "chrome/browser/media/fake_desktop_media_list.h"
 #include "chrome/browser/ui/views/desktop_media_picker_views.h"
 #include "components/web_modal/test_web_contents_modal_dialog_host.h"
@@ skipping 167 matching lines @@
 
   GetPickerDialogView()->GetMediaSourceViewForTesting(0)->OnFocus();
   EXPECT_TRUE(
       GetPickerDialogView()->IsDialogButtonEnabled(ui::DIALOG_BUTTON_OK));
 
   media_list_->RemoveSource(0);
   EXPECT_FALSE(
       GetPickerDialogView()->IsDialogButtonEnabled(ui::DIALOG_BUTTON_OK));
 }
 
+// Verifies that the MediaListView get the initial focus.
+TEST_F(DesktopMediaPickerViewsTest, ListViewHasInitialFocus) {
+  EXPECT_TRUE(GetPickerDialogView()->GetMediaListViewForTesting()->HasFocus());

[Peter Kasting, 2015/10/02 18:52:56]

I was thinking more along the lines of checking that arrows or whatever other
keys this responds to would actually change the selected item correctly.  In
other words, basically verifying all the ways to affect this from the keyboard.

[gyzhou, 2015/10/05 20:50:16]

We were verified that bool DesktopMediaListView::OnKeyPressed() will not be
executed when arrow keys are pressed. It seems that Keybaord navigation control
is done by view class in this case. This is a issue but out of the scope of this
CL. Therefore, unit test will not cover arrow keys.

For button OK/share, unit test need cover 1, button disable when there is no
selection. 2, button enable when there is a selection. 3, button clicked.

For button cancel, unit test need cover 1, button always enable. 2 button
clicked.

For mouse, unit test need cover 1, mouse left button single clicked, 2 mouse
left button doubly clicked.

Most test cases were already covered by existing unit tests. I added unit tests
for cancel button clicked and mouse left button single clicked which were
missed. 

[Peter Kasting, 2015/10/05 20:59:45]

Yes, I know this.  That's why I asked for an interactive test to verify this. 
You seem to have ignored my response to your last message, and instead just
reiterated what you already told me.

I'm not happy with the way the communication on this code review has gone.  I
shouldn't have to ask for something multiple times, but that's seemed to happen
with practically everything I've requested here.  If you don't understand what
I'm asking, please work with someone else who can help ensure you understand and
implement every request made.

[gyzhou, 2015/10/05 21:12:27]

We knew that the arrow key wasn't controlled by listview because we did test.
Otherwise, how we can know this.

[Peter Kasting, 2015/10/05 21:59:26]

I don't even understand how this sentence has any relevance to what I just said.

To reiterate: you likely can't test keyboard interactions with a unit test, you
probably need to use an interactive UI test to do more of a "full stack" test of
the interaction between inputs and the complete controllable object here.

+}
+
 }  // namespace views