>> I'm not sure since I don't have much experience with Selenium
>> assertions. But your approach seems quite cumbersome. Have you
>> considered to e.g. use the 'waitForVisible()' assertion?
Yes - this might be working ... but I had to do it all the time with
different assertions. 'waitForIdle' at least tells from the name what I'm
trying to do and could be implemented in a generic way.
>> If there is a qooxdoo method to check the queues, this shouldn't be a
problem.
If there was a method I could have called it ;-) ...
Currently I use the following to wait for the qooxdoo-queues (as a proof
of concept) and it seems to work.
Of course it could be that these two statements change timing anyway so
that it's a selffulfilling prophecy.
waitForCondition
var
tmp=selenium.browserbot.getCurrentWindow();tmp.wrappedJSObject.qx.ui.core.Widget._fastGlobalDisplayQueue.length==0
10000
waitForCondition
var tmp=selenium.browserbot.getCurrentWindow();var lazyQueueEmpty=true;for
(vKey in tmp.wrappedJSObject.qx.ui.core.Widget._lazyGlobalDisplayQueues)
{lazyQueueEmpty=false;break;};lazyQueueEmpty
10000
(Don't be confused - this is 0.7.3 qooxdoo If you still remember it ;-) )
As all this stuff looks very awful, that's why I thought about putting
such stuff in the js-extension.
>> But you are actually the first to report such an issue.
Let's wait some more, maybe we get other useful strategies.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
