On Thu, Sep 10, 2009 at 9:38 AM, James Su<[email protected]> wrote:
> Oh, I found it. So I'm wondering why not just move browser_focus_uitest into
> browser_tests? Is it because the trybot limitation (no active desktop)?

Yep.

> If
> it's the case, then what should I do for my test? Moving it into
> interactive_ui_tests is apparently not a right solution.

You could land it in interactive_ui_tests and DISABLE it for now. Talk
with Jay about the plan for splitting interactive ui tests in two.

  -Scott

> Regards
> James Su
>
> 2009/9/11 Scott Violet <[email protected]>
>>
>> Mixing IN_PROC_BROWSER_TEST with other tests causes problems (see
>> earlier thread from Pawel on this).
>>
>>  -Scott
>>
>> On Thu, Sep 10, 2009 at 9:04 AM, James Su<[email protected]> wrote:
>> > Thanks a lot for your information.
>> > I noticed that browser_focus_uitest.cc, which is in interactive ui
>> > tests,
>> > also uses IN_PROC_BROWSER_TEST and simulates key events (Tab key). I
>> > tried
>> > to move it into browser_tests and run on trybot, and amazingly it
>> > passed. I
>> > can't see any real difference between browser_focus_uitest and my test
>> > in
>> > simulating key events.
>> > Regards
>> > James Su
>> >
>> > 2009/9/10 Scott Violet <[email protected]>
>> >>
>> >> To add to what Eric says this is part of the reason for the
>> >> interactive ui tests. Interactive ui tests run logged in so that you
>> >> can generate key/mouse events and have everything work. I believe Jay
>> >> is in the process of splitting these tests up so that we could have
>> >> some interactive ui tests that use IN_PROC_BROWSER_TEST.
>> >>
>> >>  -Scott
>> >>
>> >> On Thu, Sep 10, 2009 at 7:37 AM, Erik Kay<[email protected]> wrote:
>> >> >
>> >> > Another issue to be aware of is that on the bots, they're running
>> >> > without an active desktop.  This can lead to a few things behaving
>> >> > slightly differently than your local machine.  For example, there
>> >> > will
>> >> > be no active window, so a call like
>> >> > BrowserList::GetLastActiveWithProfile(...) will always return NULL.
>> >> > One way you can simulate this behavior locally is to lock your screen
>> >> > when you run your test.  Another (less reliable) way is to quickly
>> >> > give another window focus when you launch your test.
>> >> >
>> >> > There are other differences as well, maybe others can weigh in with
>> >> > more specifics.
>> >> >
>> >> > Erik
>> >> >
>> >> >
>> >> > On Thu, Sep 10, 2009 at 3:15 AM, James Su <[email protected]> wrote:
>> >> >> Hi,
>> >> >>   Recently I'm working on an automated test of autocomplete edit
>> >> >> view,
>> >> >> see
>> >> >> CL: http://codereview.chromium.org/177052. It's an in process
>> >> >> browser
>> >> >> test.
>> >> >> It tests the functionalities of autocomplete edit view (omnibox) by
>> >> >> simulating key events. It's supposed to run on both Linux and
>> >> >> Windows,
>> >> >> and
>> >> >> it runs without any problem on both local Linux machine and Linux
>> >> >> trybot. It
>> >> >> also runs on local Windows machine, but it always fails on Windows
>> >> >> trybot.
>> >> >> Checking the log, I found that it's timed out when sending key
>> >> >> event.
>> >> >> Then
>> >> >> I'm wondering if it's a bug or limitation of windows trybot, or I
>> >> >> did
>> >> >> something wrong?
>> >> >>   And when I run the test on a local Windows machine, it sometimes
>> >> >> fails
>> >> >> with following error:
>> >> >>
>> >> >> [2820:5668:0910/131457:263873000:FATAL:navigation_controller.cc(492)]
>> >> >> Check
>> >> >> failed: !GetActiveEntry(). Got an invalid page ID but we seem to be
>> >> >>  navigated to a valid page. This should be impossible.
>> >> >> c:\chromium\src\base/test_suite.h(108): error: Failed
>> >> >>
>> >> >> [2820:5668:0910/131457:263873000:FATAL:navigation_controller.cc(492)]
>> >> >> Check
>> >> >> failed: !GetActiveEntry(). Got an invalid page ID but we seem to be
>> >> >>  navigated to a valid page. This should be impossible.
>> >> >> Backtrace:
>> >> >>         StackTrace::StackTrace [0x1029B651+33]
>> >> >> (c:\chromium\src\base\debug_util_win.cc:226)
>> >> >>         logging::LogMessage::~LogMessage [0x1025DDFA+618]
>> >> >> (c:\chromium\src\base\logging.cc:540)
>> >> >>         NavigationController::ClassifyNavigation [0x1055B094+180]
>> >> >>
>> >> >>
>> >> >> (c:\chromium\src\chrome\browser\tab_contents\navigation_controller.cc:494)
>> >> >>         NavigationController::RendererDidNavigate [0x1055ACD6+198]
>> >> >>
>> >> >>
>> >> >> (c:\chromium\src\chrome\browser\tab_contents\navigation_controller.cc:424)
>> >> >>         TabContents::DidNavigate [0x1062DF98+248]
>> >> >> (c:\chromium\src\chrome\browser\tab_contents\tab_contents.cc:1953)
>> >> >>         RenderViewHost::OnMsgNavigate [0x105710EB+459]
>> >> >>
>> >> >> (c:\chromium\src\chrome\browser\renderer_host\render_view_host.cc:955)
>> >> >> ...
>> >> >>   Is it a bug of chrome or something wrong in my test?
>> >> >> Regards
>> >> >> James Su
>> >> >> >
>> >> >>
>> >> >
>> >> > >> >> >
>> >> >
>> >
>> >
>
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to