Extract locking behaviour from ProcessSingleton.

chrome/browser/process_singleton_modal_dialog_lock.h

+// 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.
+
+#ifndef CHROME_BROWSER_PROCESS_SINGLETON_MODAL_DIALOG_LOCK_H_
+#define CHROME_BROWSER_PROCESS_SINGLETON_MODAL_DIALOG_LOCK_H_
+
+#include "base/basictypes.h"
+#include "base/callback_forward.h"
+#include "chrome/browser/process_singleton.h"
+#include "ui/gfx/native_widget_types.h"
+
+class CommandLine;
+
+namespace base {
+class FilePath;
+}
+
+// Provides a ProcessSingleton::NotificationCallback that prevents
+// command-line handling when a modal dialog is active.
+//
+// While a dialog is active, the ProcessSingleton notification

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

Explain what "a dialog is active" means as far as this class is concerned (i.e.,
|active_dialog_| is set; it's far from monitoring all dialogs shown by Chrome).

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

I've added "during startup". I think that the definition of a modal dialog being
active is pretty self-defined (modal meaning that it blocks interaction with the
app).

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

Well that's better, but what I mean is that this comment makes it feel like this
class is globally aware of all modal dialogs active during startup which is not
true.

I would instead change it to something like "when |active_dialog_| is set." so
that readers explicitly know this class has to be notified somehow for this to
take action.

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

OK, now your concern is clear to me. I added some content - WDYT?

+// callback will handle but ignore notifications (i.e., neither this process

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

will handle notifications by bringing the dialog to the foreground (ignoring the
provided command line).

?

I don't like that the important part (bringing to foreground) seems like a
detail in the current wording; I think it should be the main point and the fact
that the command line is ignored the "detail".

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

Reformatted.

+// nor the invoking process will handle the command line) and the dialog is
+// brought to the foreground.
+//
+// Otherwise, the notification is forwarded to a wrapped NotificationCallback.
+class ProcessSingletonModalDialogLock {
+ public:
+  typedef base::Callback<void(gfx::NativeWindow)> SetForegroundWindowHandler;
+  explicit ProcessSingletonModalDialogLock(
+      const ProcessSingleton::NotificationCallback& original_callback);
+
+  ProcessSingletonModalDialogLock(
+      const ProcessSingleton::NotificationCallback& original_callback,
+      const SetForegroundWindowHandler& set_foreground_window_handler);
+
+  ~ProcessSingletonModalDialogLock();
+
+  // Receives a handle to the active modal dialog, or NULL if the active dialog
+  // is dismissed.
+  void SetActiveModalDialog(gfx::NativeWindow active_dialog);
+
+  // Returns the callback that should be supplied to ProcessSingleton.
+  // The callback is only valid during the lifetime of the
+  // ProcessSingletonModalDialogLock instance.

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

Same comments on the comment here (ref. identical comment on
ProcessSingletonStartupLock).

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

See my response there.

+  ProcessSingleton::NotificationCallback AsNotificationCallback();
+
+ private:
+  bool NotificationCallbackImpl(const CommandLine& command_line,
+                                const base::FilePath& current_directory);
+
+  gfx::NativeWindow active_dialog_;
+  ProcessSingleton::NotificationCallback original_callback_;
+  SetForegroundWindowHandler set_foreground_window_handler_;
+
+  DISALLOW_COPY_AND_ASSIGN(ProcessSingletonModalDialogLock);
+};
+
+#endif  // CHROME_BROWSER_PROCESS_SINGLETON_MODAL_DIALOG_LOCK_H_