diff options
author | scottbyer@chromium.org <scottbyer@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-02-27 19:05:29 +0000 |
---|---|---|
committer | scottbyer@chromium.org <scottbyer@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-02-27 19:05:29 +0000 |
commit | d81d40b5f5f5728238f7743960adf3d1b16ff4aa (patch) | |
tree | a1b5288aec9ea87fc2e9f3c713e867c208624a84 /chrome/browser/automation/automation_provider_list_generic.cc | |
parent | ee47b5069b4b2819b244908d4e640a32c95c6b44 (diff) | |
download | chromium_src-d81d40b5f5f5728238f7743960adf3d1b16ff4aa.zip chromium_src-d81d40b5f5f5728238f7743960adf3d1b16ff4aa.tar.gz chromium_src-d81d40b5f5f5728238f7743960adf3d1b16ff4aa.tar.bz2 |
Refactor out foreground_help to fix BringBrowserWindowToFront on Windows
Refactor out foreground_helper so that regular Chromium tests can use it. Use
it in ShowAndFocusNativeWindow to make sure the browser window is in front,
both when tests ask and when trying to send keyboard events. This should reduce
some flakiness of related tests, and certainly makes it easier to debug those
tests.
The API for SendKeyPress events looks like it changed long ago to add a target
window, only the Windows code simply dropped that on the floor. By returning
false when the event wouldn't go to the right place, it allows for
ui_test_utils::SendKeyPressSync to bring the browser window to the front and
try again.
BUG=106489
TEST=Run browser_tests or interactive_ui_tests and bring another window to the
front. For the tests in question, the browser should now pop in front when it
needs to for the test to complete properly.
Review URL: http://codereview.chromium.org/9431050
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@123771 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/automation/automation_provider_list_generic.cc')
0 files changed, 0 insertions, 0 deletions