Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(321)

Issue 7038026: Add a NavBarCheck test case for OptionsUITest. (Closed)

Created:
9 years, 7 months ago by xiyuan
Modified:
9 years, 7 months ago
Reviewers:
csilv, Ilya Sherman, zel
CC:
chromium-reviews, Paweł Hajdan Jr.
Visibility:
Public.

Description

Add a NavBarCheck test case for OptionsUITest. - Add WaitForOptionsUI and GetOptiosnUITab that follows BookmarksUITest; - Use the two function for LoadOptionsByURL and hopefully this makes the test no longer flaky; - Add a NavBarCheck test that check settings page is loaded properly and all expection sections are present; BUG=chromium:77375, chromium-os:15417 TEST=Verify LoadOptionsByURL no longer flaky and new NavBarCheck passes on all platforms. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=85813

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+60 lines, -9 lines) Patch
M chrome/browser/ui/webui/options/options_ui_uitest.cc View 3 chunks +60 lines, -9 lines 0 comments Download

Messages

Total messages: 5 (0 generated)
xiyuan
9 years, 7 months ago (2011-05-17 23:57:04 UTC) #1
zel
LGTM++
9 years, 7 months ago (2011-05-18 00:14:31 UTC) #2
csilv
LGTM
9 years, 7 months ago (2011-05-18 19:14:50 UTC) #3
Ilya Sherman
For posterity, could you explain why the call to tab->NavigateToURL() does not block sufficiently? Should ...
9 years, 7 months ago (2011-05-18 22:55:46 UTC) #4
xiyuan
9 years, 7 months ago (2011-05-18 23:36:12 UTC) #5
On 2011/05/18 22:55:46, Ilya Sherman wrote:
> For posterity, could you explain why the call to tab->NavigateToURL() does not
> block sufficiently?  Should we perhaps update that code to block correctly for
> all clients, or is there something extra-special about the case being tested
> here that I'm overlooking?
> 
> Thanks,
> ~ilya

The change is based on what I saw in BookmarksUITest that runs fine on all
platforms. I think the reason behind this is like this:
tab->NavigateToURL() and UITest::NavigateToURL are both based on LOAD_STOP
notification which is triggered from renderer's didStopLoading. It is based on
navigation status change. This should normally be good enough.

But settings page, like bookmarks manager, does quite some extra init work on
DOMContentLoaded event and it might not be ready when navigation stops.The extra
wait to check document.readyState in javascript ensures DOM tree is ready.

I think it is only necessary for cases that does fair amount work on
DOMContentLoaded and needs to be sure that DOM tree is ready before testing code
starts to poke around.

Cheers
Xiyuan

Powered by Google App Engine
This is Rietveld 408576698