Extract locking behaviour from ProcessSingleton.

chrome/browser/process_singleton_modal_dialog_lock.cc

+// Copyright (c) 2013 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 "chrome/browser/process_singleton_modal_dialog_lock.h"
+
+#if defined(OS_WIN)
+#include <Windows.h>
+#endif
+
+#include "base/bind.h"
+#include "base/command_line.h"
+#include "base/files/file_path.h"
+#include "base/logging.h"
+
+namespace {
+
+#if !defined(OS_WIN) || defined(USE_AURA)

[gab, 2013/03/28 13:45:53]

Are you splitting the method in two ifdef'd impls because of compile issues?

I thought gfx::NativeWindow was typedef'd to HWND on Win (non-Aura) anyways..?

[erikwright (departed), 2013/04/04 01:39:51]

On Windows, these two signatures are equivalent. On all other platforms, only
the first one will compile. So, yes, this is because we have to delegate to a
platform specific call (which we only actually use on Windows anyway, and for
which I don't have an equivalent on other platforms).

+void DoSetForegroundWindow(gfx::NativeWindow /* target_window */) {
+  NOTREACHED();
+}
+#else
+void DoSetForegroundWindow(HWND target_window) {
+  ::SetForegroundWindow(target_window);
+}
+#endif
+
+}  // namespace
+
+ProcessSingletonModalDialogLock::ProcessSingletonModalDialogLock(
+    const ProcessSingleton::NotificationCallback& original_callback)
+    : active_dialog_(NULL),
+      original_callback_(original_callback),
+      set_foreground_window_handler_(base::Bind(&DoSetForegroundWindow)) {}
+
+ProcessSingletonModalDialogLock::ProcessSingletonModalDialogLock(
+    const ProcessSingleton::NotificationCallback& original_callback,
+    const SetForegroundWindowHandler& set_foreground_window_handler)
+    : active_dialog_(NULL),
+      original_callback_(original_callback),
+      set_foreground_window_handler_(set_foreground_window_handler) {}
+
+ProcessSingletonModalDialogLock::~ProcessSingletonModalDialogLock() {}
+
+void ProcessSingletonModalDialogLock::SetActiveModalDialog(
+    gfx::NativeWindow active_dialog) {
+  active_dialog_ = active_dialog;
+}
+
+ProcessSingleton::NotificationCallback
+ProcessSingletonModalDialogLock::AsNotificationCallback() {
+  return base::Bind(&ProcessSingletonModalDialogLock::NotificationCallbackImpl,
+                    base::Unretained(this));
+}
+
+bool ProcessSingletonModalDialogLock::NotificationCallbackImpl(
+      const CommandLine& command_line,
+      const base::FilePath& current_directory) {
+  if (active_dialog_ != NULL) {
+    set_foreground_window_handler_.Run(active_dialog_);

[gab, 2013/03/28 13:45:53]

I don't really see a use-case for using a callback here, I feel calling
DoSetForegroundWindow() directly is clearer and avoids an unnecessary layer of
indirection.

I also don't like having two constructors only to support this unnecessary
use-case.

Consider removing the use of a callback here and calling DoSetForegroundWindow()
directly.

[erikwright (departed), 2013/04/04 01:39:51]

This mechanism support unit-testing. Please see the unit-test in
process_singleton_unittest_win.cc .

[gab, 2013/04/04 02:31:45]

Ah nice, had somehow missed the test.

QQ, why not make the test-only constructor private and make the test a friend of
this class?

[erikwright (departed), 2013/04/07 02:27:29]

I find friend declarations harmful and distasteful. It opens the entire class up
in order to reveal a single function. On the other hand, there is basically zero
harm in exposing a constructor like this, especially given that this class is
analogous to a concrete implementation of a pure-virtual interface (i.e., the
end user only gets access to a single Callback, so the other public details of
the implementing class are not exposed).

+    return true;
+  } else {
+    return original_callback_.Run(command_line, current_directory);
+  }
+}