MacViews: Fix ViewTest.HandleAccelerator by faking window activation

ui/views/test/views_test_helper_mac.mm

 // 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 "ui/views/test/views_test_helper_mac.h"
 
 #import <Cocoa/Cocoa.h>
 
 #import "base/mac/scoped_nsautorelease_pool.h"
+#include "ui/base/test/scoped_fake_nswindow_focus.h"
 #include "ui/compositor/scoped_animation_duration_scale_mode.h"
 #include "ui/views/test/event_generator_delegate_mac.h"
 #include "ui/views/widget/widget.h"
 
 namespace views {
 
 // static
 ViewsTestHelper* ViewsTestHelper::Create(base::MessageLoopForUI* message_loop,
                                          ui::ContextFactory* context_factory) {
   return new ViewsTestHelperMac;
@@ skipping 19 matching lines @@
   // then a lot of confusing use-after-free errors result. In browser tests,
   // this is handled automatically by views::Widget::CloseAllSecondaryWidgets().
   // Unit tests on Aura may create Widgets owned by a RootWindow that gets torn
   // down, but on Mac we need to be more explicit.
   base::mac::ScopedNSAutoreleasePool pool;  // Ensure the NSArray is released.
   NSArray* native_windows = [NSApp windows];
   for (NSWindow* window : native_windows)
     DCHECK(!Widget::GetWidgetForNativeWindow(window)) << "Widget not closed.";
 }
 
+void ViewsTestHelperMac::EnableFakeWindowActivation() {
+  faked_focus_.reset(new ui::test::ScopedFakeNSWindowFocus);

[sky, 2016/03/10 18:59:16]

Is there a reason not to do this always? By that I mean move this code to the
constructor?

[tapted, 2016/03/11 09:56:19]

Done (see what you think).

This has actually crossed my mind a few times already.. I don't think
interactive_ui_tests should get it so there's some non-fake coverage of
activation flows. Also at least one  test --
NativeWidgetMacInteractiveUITest.ParentWindowTrafficLights -- would regress
since there's some native behaviour that we can't fake. But apart from that, I
think I was just being conservative.

So I've explored how this would look, including logic to prevent the faker
getting installed for interactive_ui_tests - ptal.

+}
+
 }  // namespace views