Firefox overlay is seen opened even if Import Overlay is Cancelled.

chrome/browser/ui/cocoa/importer/import_lock_dialog_cocoa.mm

 // Copyright (c) 2011 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.
 
 #import <Cocoa/Cocoa.h>
 
 #include "base/bind.h"
 #include "base/callback.h"
 #include "base/mac/scoped_nsobject.h"
 #include "base/metrics/user_metrics.h"
@@ skipping 18 matching lines @@
       IDS_IMPORTER_LOCK_TEXT)];
   [lock_alert setMessageText:l10n_util::GetNSStringWithFixup(
       IDS_IMPORTER_LOCK_TITLE)];
 
   base::ThreadTaskRunnerHandle::Get()->PostTask(
       FROM_HERE,
       base::Bind(callback, [lock_alert runModal] == NSAlertFirstButtonReturn));
   base::RecordAction(UserMetricsAction("ImportLockDialogCocoa_Shown"));
 }
 
+void HideImportLockDialog() {
+  // This code path is not needed for Mac, as the user must explicitly close
+  // the sheet before any situation can arise in which we'd need to close it
+  // programmatically. See https://crbug.com/672428 for more details.

[msw, 2017/04/06 00:12:27]

Views should probably instead use a tab or browser-modal dialog to prevent
interaction with the import dialog while the lock dialog is showing? That would
make Views match Cocoa in behavior, and make the weird sub-dialog closing logic
unnecessary.

All you should need for browser window modality is to pass the |parent| to
CreateDialogWidget and override ImportLockDialogView::GetModalType() to return
ui::MODAL_TYPE_WINDOW. For tab modality, see users of
constrained_window::ShowWebModalDialogViews

+}
+
 }  // namespace importer