ui_test_utils::NavigateToURLBlockUntilNavigationsComplete can be raced

ui_test_utils::NavigateToURLBlockUntilNavigationsComplete can be raced

I found in some prefetching safe browsing tests that chrome went so
awesomely fast that events went by before NavigateToURL started
observing them.  And so I adapted the Windowed.... model to the
NavigationNotificationObserver, and use that now in NavigateToURL in
the current_tab case.

BUG=75507
TEST=see http://codereview.chromium.org/6334131/

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

[gavinp, 2011-03-09 21:42:58]

While hacking on http://codereview.chromium.org/6334131/ I found I was racing
tests.

This CL fixes that for me, the unit test in the abovementioned review always
fails on my machine without this change.

[sky, 2011-03-09 21:52:50]

http://codereview.chromium.org/6662001/diff/1/chrome/test/ui_test_utils.cc
File chrome/test/ui_test_utils.cc (right):

http://codereview.chromium.org/6662001/diff/1/chrome/test/ui_test_utils.cc#ne...
chrome/test/ui_test_utils.cc:87: MessageLoopForUI::current()->Quit();
Doesn't this mean Quit may be invoked before Run? Who knows what problems that
may cause. This code should only quit if Run was invoked, and similarly Run
should only Run if needed.

Also, add some documentation that describes the two cases.

[gavinp, 2011-03-09 22:17:18]

Thanks sky!  Does this upload address those concerns?

[sky, 2011-03-09 22:43:41]

LGTM

[Paweł Hajdan Jr., 2011-03-10 16:06:58]

Gavin, thank you for detecting and fixing the issue. I'm afraid we have very
similar code in chrome/browser/automation (probably automation_observers.cc).
Could you take a look there? It could explain some weird bugs in ui_tests and
others.