diff options
| author | isherman@chromium.org <isherman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-24 08:06:04 +0000 |
|---|---|---|
| committer | isherman@chromium.org <isherman@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-09-24 08:06:04 +0000 |
| commit | 095b55f695d7a576305a06e9d8f63669d2c9baa5 (patch) | |
| tree | 8d5519ad8d1a6ac3ccbab01ff5ab5b5e5d9b3ab9 /chrome/browser/browser_keyevents_browsertest.cc | |
| parent | a8fa243a05207629542fd74350aca146b840efda (diff) | |
| download | chromium_src-095b55f695d7a576305a06e9d8f63669d2c9baa5.zip chromium_src-095b55f695d7a576305a06e9d8f63669d2c9baa5.tar.gz chromium_src-095b55f695d7a576305a06e9d8f63669d2c9baa5.tar.bz2 | |
Experimental change to try to reduce the flakiness of BrowserKeyEventsTest.AccessKeys
The theory is that the QuitTask might be nestling into the message loop before the task for the result of the key press. For example, in bug 55713, the theory is that we quit out of the message loop after the key press is sent, but before the location bar is focused.
If so, this patch should serve as a band-aid to (nearly) eliminate the test flakiness. At that point we can try to figure out a more bulletproof fix; for now, I'd like to make sure we're right about the underlying cause of the flakiness.
BUG=55713
TEST=interactive_ui_tests --gtest_filter=BrowserKeyEventsTest.AccessKeys should not flakily fail
Review URL: http://codereview.chromium.org/3454025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60437 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/browser_keyevents_browsertest.cc')
| -rw-r--r-- | chrome/browser/browser_keyevents_browsertest.cc | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/chrome/browser/browser_keyevents_browsertest.cc b/chrome/browser/browser_keyevents_browsertest.cc index 02f8727..6d3c589 100644 --- a/chrome/browser/browser_keyevents_browsertest.cc +++ b/chrome/browser/browser_keyevents_browsertest.cc @@ -630,6 +630,11 @@ IN_PROC_BROWSER_TEST_F(BrowserKeyEventsTest, MAYBE_AccessKeys) { #if !defined(OS_MACOSX) // Alt+D should move the focus to the location entry. EXPECT_NO_FATAL_FAILURE(TestKeyEvent(tab_index, kTestAccessD)); + + // TODO(isherman): This is an experimental change to help diagnose + // http://crbug.com/55713 + ui_test_utils::RunAllPendingInMessageLoop(); + EXPECT_TRUE(IsViewFocused(VIEW_ID_LOCATION_BAR)); // No element should be focused, as Alt+D was handled by the browser. EXPECT_NO_FATAL_FAILURE(CheckFocusedElement(tab_index, L"")); |