browser_tests on Mac doesn't activate application

[Bernhard Bauer]

Does anyone know why running browser_tests on Mac does not bring the application to the front the same way running regular Chrome does? I even tried manually calling [NSApp activateIgnoringOtherApps:YES] and that didn't do anything either.

(The reason I'm asking is because a recent bug (https://crbug.com/460859) could have been caught by browser tests if the app would be activated or get an applicationDidFinishLaunching: callback. I could imagine there are other cases as well where the behavior of browser_tests diverges from Chrome in a way that reduces test coverage).

Thanks,

Bernhard.

[Marc-Antoine Ruel]

2015-02-23 11:30 GMT-05:00 Bernhard Bauer <bau...@chromium.org>:

Does anyone know why running browser_tests on Mac does not bring the application to the front the same way running regular Chrome does? I even tried manually calling [NSApp activateIgnoringOtherApps:YES] and that didn't do anything either.

(The reason I'm asking is because a recent bug (https://crbug.com/460859) could have been caught by browser tests if the app would be activated or get an applicationDidFinishLaunching: callback. I could imagine there are other cases as well where the behavior of browser_tests diverges from Chrome in a way that reduces test coverage).

browser_tests != interactive_ui_tests. There's multiple concurrent instances running, so it's fairly possible an instance never gets the chance to have the OS Window be activated for real.

M-A

[Trent Apted]

tl;dr you probably want ui_test_utils::ShowAndFocusNativeWindow()

browser_tests isn't given an "activation policy" on Mac. Applications on Mac that are just binaries (i.e. not in a .app bundle) have a default activation policy of NSApplicationActivationPolicyProhibited meaning it can't get key status and effectively ignores [NSApp activateIgnoringOtherApps]. Calling  [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular] will give it "normal" behavior. *But* keep reading..

A Cocoa interactive_ui_test on Mac can call ui_test_utils::ShowAndFocusNativeWindow which (instead of setActivationPolicy) does TransformProcessType(&psn,kProcessTransformToForegroundApplication). Which probably amounts to the same thing.

You're probably not doing toolkit-views on Mac (I haven't flipped that flag yet :p) but a bunch of interactive_ui_tests for that on Mac inherit from ViewsTestBase which calls code in ViewsTestHelperMac that does [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; to allow some tests to work in a sane manner. But as Marc-Antoine points out, you still need to be careful that browser_tests run in parallel and you can't rely on things like [NSApp keyWindow] giving a sane/non-flaky answer on they trybots.

And of course the usual caveat applies -- interactive_ui_tests generally suck (they are slow and flaky) and if you can get the same coverage in a browser_test, chromium is generally better off. You might be interested in ui::test::EventGenerator, but EventGeneratorDelegateMac needs to be moved out of "toolkit-views" (it didn't have a client outside of toolkit-views, but there's not really a views dependency). views::test::InitializeMacEventGeneratorDelegate() needs to be called, which only happens in a toolkit-views build.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev