[Webtest] [dev] support for js confirm()...

[Marc Guillemot]

Hi Costin,


>>What do you think (I can develop more if needed)?
> 
> Why do you need two threads? Isn't that going to make the architecture
> more complex? 

it does, but if we can find a better solution, I'm interested in.

 > Why not enable some sort of interceptor (additional
> plugable layer) for the javascript functionality?
> 
> If the button or link has some javascript properties, the
> 'interceptor' will check the condition and affect the overall result.
> 
> On short, in our project we had this 'places' where the user could
> insert certain conditions in the workflow - to deal with them we
> created a stack of event, user configurable, that were executed before
> the result was concluded by the same thread.
> 
> Just an idea..

the problem is as follows:
1- the execution of a clickbutton (for instance) calls webPage.click(...)
2- this trigers the execution of a javascript:confirm
3- htmlunit calls back the ConfirmHandler we have registered

what to do now:
we are always in the <clickbutton> step and we have to terminate it before executing the next step. With  2 threads, the 
"webclient" thread could start sleeping in the ConfirmHandler until we notify it that is has to check for a js 
confirmation. With a single thread... it would require that the ConfirmHandler knows what to do before the <clickbutton> 
step terminates. In other terms that a step (the <jsConfirm>) gets evaluated before the previous step in the queue (the 
<clickbutton> step). Quite complex. I think that in this case 2 threads would reduce the complexity, but perhaps can you 
convince me that I'm wrong.

Marc.