[Webtest] RE[2]: [dev] support for js confirm()...

[Costin]

>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.
I don't have any insights about the project so I cannot do this at
this point. If the queue concept it's too complex than I guess having
two threads is the way to go. However, I think having a buffer(FIFO)
is better because you have only one thread and you don't get into
thread syncronization. Then again, if you have only two threads is
easy to synchronize them.

However, I think the FIFO idea is more scalable because the overhead
is smaller (consider there are more javascript elements in a tag).
Plus, this problem sounds like a queue/buffer and not like concurrent
access.

Anyways, as I said I don't know the internals so I can be simply raving here.

Costin