Remove ash-chrome special handling in BrowserView::CanAcrivate

The special handing calls ActivateAppModalDialog synchrounously
which causes infinite recursion. On other platform, the problem is
fixed by posting a task to call ActivateAppModalDialog and ChromeOS
should follow.

The ChromeOS special handing fixes a crash when creating js
modal dialog under an active lock screen (http://crbug/226141).
This crash no longer happens, with or without the synchronous call.

Bug: 1287282
Change-Id: I6b4ac46e93e5c85336a37ae461a6e554847e5cc3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3553683
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#985667}

chrome/browser/ui/views/frame/browser_view.cc

@@ -2773,19 +2773,13 @@ bool BrowserView::CanActivate() const {
     return true;
   }
 
-#if defined(USE_AURA) && BUILDFLAG(IS_CHROMEOS_ASH)
-  // On Aura window manager controls all windows so settings focus via PostTask
-  // will make only worse because posted task will keep trying to steal focus.
-  queue->ActivateModalDialog();
-#else
   // If another browser is app modal, flash and activate the modal browser. This
   // has to be done in a post task, otherwise if the user clicked on a window
   // that doesn't have the modal dialog the windows keep trying to get the focus
   // from each other on Windows. http://crbug.com/141650.
   base::ThreadTaskRunnerHandle::Get()->PostTask(
       FROM_HERE, base::BindOnce(&BrowserView::ActivateAppModalDialog,
                                 weak_ptr_factory_.GetWeakPtr()));
-#endif
   return false;
 }