[Windmill-dev] waits.forElement broken?

[Mikeal Rogers]

To clarify, I'm not even talking about the IDE UI. I don't care about  
the IDE UI for this, the public windmill API implementation is broken.

By "returns" i mean the IDE is resolving the action in the service as  
being completed before the timeout, causing the test to move on to the  
next action (in this unittest case it'll actually move on to validate  
the time delta before and after calling it and then fail in an assert).

If the IDE turns green before the action is completed that sounds like  
a bug to me, but a different bug than the one I'm addressing here. The  
IDE should turn red/green at the same time it finishes the current  
action and tells the service, preferably right after it calls  
resolve() in the service and before it calls next_action(). In the  
case of the js test framework after report_without_resolve() is called  
in the service.

I don't actually understand the semantics you describe below,  
specifically I don't understand why the IDE UI state of red/green is  
tied directly to what seems to be an intermediate step in the  
resolution of the action. This sounds like a bug, or maybe an  
architectural discrepancy.

-Mikeal


On Dec 26, 2007, at December 26, 200710:50 PM, Matthew Eernisse wrote:

> Mikeal,
>
> I was asking for some clarification, because "returns true and  
> returns immediately" describes the current *expected* (and  
> admittedly counter-intuitive) behavior.
>
> Mikeal Rogers wrote:
>> Matt, waits are completely broken. They return immediately no  
>> matter what and always return true, even in the case of forElement  
>> the timeout expires without satisfying the condition.
>
> Under the hood, the waits.forElement method returns a true value  
> right away, *as soon as it's called* (the action in the IDE turns  
> green, etc.), but it still should wait until it either finds the  
> element, or times out to start running the next action.
>
> Here's a snippet from the Output (where entries at the top are newer  
> than those at the bottom):
>
> Looking up id fooBarBaz
> Element id=fooBarBaz not found
> Looking up id fooBarBaz
> Element id=fooBarBaz not found
> Looking up id fooBarBaz
> Element id=fooBarBaz not found
> Looking up id fooBarBaz
> Element id=fooBarBaz not found
>
> Action: waits.forElement
> Parameters:  
> {"uuid 
> ":"1198737527765 
> ","timeout":"12000","id":"fooBarBaz","test":"undefined"}
> Test Result: true
> Looking up id fooBarBaz
> Element id=fooBarBaz not found
>
> It returns true, and then proceeds to sit and wait, looking for the  
> element.
>
> Simply saying it "returns true and returns immediately" doesn't tell  
> us whether this is the known brokenness of the current  
> implementation, or some other, new bug. The important question is  
> whether or not it's running the next action immediately or not.
>
> Robert is saying it's running the next action with no delay, which  
> indicates the latter. Sounds like we're going to have to do some  
> digging.
>
>
> Matthew
>
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev