Mac: Use activateIgnoringOtherApps instead of SetFrontProcessWithOptions to focus app windows

Mac: Use activateIgnoringOtherApps instead of SetFrontProcessWithOptions to focus app windows

Yet another attempt at finding a workaround for the two-windows-have-key-
status bug that can affect packaged app windows on Mac.

Currently, NativeAppWindowCocoa activates Chrome with
::SetFrontProcessWithOptions() called via +[BrowserWindowUtils
activateWindowForController:]. ChromeNativeAppWindowViewsMac calls
-[NSApplication activateIgnoringOtherApps:YES].

After running with the MacViews app window flag for a month I didn't encounter
this bug. Minutes after disabling the flag and returning to
NativeAppWindowCocoa, I got a repro. (Although, a week later, not a second repro).

SetFrontProcess() is deprecated with the note in HIServices/../Processes.h:
 *  Deprecated:
 *    To make your own application frontmost, use
 *      [[NSApplication sharedApplication] activateIgnoringOtherApps: YES].

SetFrontProcessWithOptions() is deprecated with the note:
 *  Deprecated:
 *    See SetFrontProcess().

We lose the `kSetFrontProcessFrontWindowOnly` argument to "bring only the
frontmost non-floating window forward", but a quick check suggests this is the
default for activateIgnoringOtherApps: anyway.

SetFrontProcessWithOptions() has been around since http://crrev.com/6647009

BUG=459306
Committed: https://crrev.com/3c44dfef03524ac42b74916de37248bb4cb919c8
Cr-Commit-Position: refs/heads/master@{#342773}

[tapted, 2015-08-10 04:28:51]

tapted@chromium.org changed reviewers:
+ rsesek@chromium.org

[tapted, 2015-08-10 04:46:57]

Hi Robert - please take a look.

I'm clutching at straws really.. I tried making a test app that mashes
window.focus() in various ways, but I was never able to repro what happens with
hangouts. I think it must be a specific timing thing with the way Hangouts
processes messages. I've been unable to find steps to replicate it at will. The
only reliable repro I've had was the one involving minimize, at
crbug.com/459306#c17, which has been fixed for a while.

But the behaviour of this CL should be identical, and it doesn't use deprecated
functions, which is nice.

If there are no surprises, we should probably just remove
activateWindowForController as well (I think it's just panels relying on that,
which we're also trying to deprecate outside of ChromeOS).

[Robert Sesek, 2015-08-11 00:53:40]

LGTM. It seems like a reasonable hypothesis that using two different activation
methods could cause this bug.

[tapted, 2015-08-11 00:57:21]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-08-11 00:57:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1278073002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1278073002/1

[commit-bot: I haz the power, 2015-08-11 01:43:09]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-08-11 01:43:45]

Patchset 1 (id:??) landed as
https://crrev.com/3c44dfef03524ac42b74916de37248bb4cb919c8
Cr-Commit-Position: refs/heads/master@{#342773}