In a discussion with Amit and Joel, we've determined that the tests that this will apply to do not use History tokens, so the repeated timeout won't apply. We couldn't think of any other cases where there would be lingering JavaScript jobs. TODO - we should revisit this issue at some point and come up with something more stable.
On 2009/08/20 20:27:25, kathrin wrote: > Hi Amit, > I think this is the right direction! But I do think there's still a problem > here, if I read the HtmlUnit documentation correctly. It says: > ----- > waitForBackgroundJavaScriptStartingBefore > This method blocks until all background JavaScript tasks scheduled to start > executing before (now + delayMillis) have finished executing. Background > JavaScript tasks are JavaScript tasks scheduled for execution via > window.setTimeout, window.setInterval or asynchronous XMLHttpRequest. > ... > Returns: > the number of background JavaScript jobs still executing or waiting to > be executed when this method returns; will be 0 if there are no jobs left to > execute > ----- > Now what's happening here is that you wait x ms for the jobs to finish, but then > there will at least be 1 still running (because GWT apps have a setTimeout(200?) > that keeps setting a setTimeout(200) to check whether the history has changed. > So unless I'm missing something, every time this method returns, it'll return a > value > 0, which means you'll just loop around until the test times out. Am I > missing something? > http://gwt-code-reviews.appspot.com/62802/diff/1/2 > File user/src/com/google/gwt/junit/RunStyleHtmlUnit.java (right): > http://gwt-code-reviews.appspot.com/62802/diff/1/2#newcode101 > Line 101: + JAVASCRIPT_WAIT_TIME + " ms"); > Rephrase a bit? Maybe say "Waiting for (++count) javascript jobs for xxx ms" http://gwt-code-reviews.appspot.com/62802 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
