Explicitly activeIgnoringOtherApps from IDC_NEW{,_INCOGNITO}_WINDOW...

Explicitly activeIgnoringOtherApps from IDC_NEW{,_INCOGNITO}_WINDOW
in app_controller_mac.mm, under the assumption we're either already
the foreground app or should become the foreground mac
(when created from the dock menu).
BUG=22595
TEST="New Window" or "New Incognito Window" from dock menu with other app in foreground

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=28091

[sgk, 2009-10-05 20:38:22]

Based on mmentovai's suggestion that we always want to active and bring chrome
to foreground in this context (see comment in the CL), this seems a
simplest-possible way to do that.  I'm unsure of possible unintended test
implications to this way of doing it; ui_tests failed on one buildbot run, but a
resubmit passed so it seems to have been transient.

[John Grabowski, 2009-10-05 22:28:57]

I'm worried about the test implications of this.  I believe the automation
provider sends these commands; we don't want it grabbing focus.

Can't we have the dock menu call a new method of whatever, named
-newWindowFromDock:, which does
a) [NSApp activateIgnoringOtherApps:YES];
b) [blah commandDispatch:IDC_NEW_BLAH];
That way unit tests / automation provider won't be impacted.

[sgk, 2009-10-05 23:54:04]

Another approach.

[John Grabowski, 2009-10-05 23:56:32]

On 2009/10/05 23:54:04, sgk wrote:
> Another approach.

LGTM

(Feels cleaner, yes?)

[sgk, 2009-10-06 03:56:10]

TBR=jrg

Added unit test update for the changed action.  (Try servers, yay!)

[John Grabowski, 2009-10-06 04:11:29]

LGTM.Unit test yay!

jrg


On Mon, Oct 5, 2009 at 8:56 PM, <sgk@chromium.org> wrote:

> TBR=jrg
>
> Added unit test update for the changed action.  (Try servers, yay!)
>
>
> http://codereview.chromium.org/256054
>