onblur/onkeyup event

[bat]

hello,

from the corresponding forum entries i take it that neither onblur nor onkeyup are supported by webtest at this time.

1. is this correct?
2. are there any plans to include support for these events in the future?
3. is there any workaround for that right now?

thanks a lot for your help
christian

[Marc Guillemot]

Hi Christian,

1. yes

2. in a first time this is an htmlunit issue. There is no "plan" just
waiting that someone proposes a good patch.
Then it needs to be usable from WebTest. For onblur it would be
transparent in most of the cases. For keyup webtest would need an
additional way to say that key have been pressed.

3. it depends a bit from what your handlers are doing.

Marc.

bat wrote:

> hello,
>
> from the corresponding forum entries i take it that neither onblur nor
> onkeyup are supported by webtest at this time.
>
> 1. is this correct?
> 2. are there any plans to include support for these events in the future?
> 3. is there any workaround for that right now?
>
> thanks a lot for your help
> christian

_______________________________________________
WebTest mailing list
WebTest@...
http://lists.canoo.com/mailman/listinfo/webtest

[bat]

hi,

i have an input field which calls a javascript function upon onblur/onkeyup that does a check on the content of the specified textbox.
under certain conditions, a message is to be displayed by changing the visibility and innerText-property of another html element.

so what's going on is basically the following:
-----------------------------------------------------------
application_behaviour.js:
var myrules = {
//...
'#txtInput' : function( element )
{
  element.onblur = function()
  {
     //...
     check( this.value );
  }
 //...
  element.onkeyup  = function()
  {
    //...
    check( this.value );
  }
  //..
};
Behaviour.register(myrules);
-----------------------------------------------------------

-----------------------------------------------------------
page.html:
function check(value)
{
  //...
  document.getElementById(id).innerHTML = someText;
  document.getElementById(div1).style.visibility = "visible";
  document.getElementById(div2).style.visibility = "visible";
}
-----------------------------------------------------------

i have experimented a bit with <scriptStep>, but that doesn't seem to work.
apparantly for the same reason you mentioned here:

"there is a fundamental misunderstanding with the <scriptStep>: it allows to script webtest and ant, not to run script in the current page.
You can use <scriptStep> as well as <groovy> to script webtest and through webtest you can access the current page and start the execution of a javascript script in it. You have to look a the API of webtest and htmlunit for it. There is currently no special documentation for it as the right way would be to write a special step first not the doc for the hack."

unfortunately i cannot figure out how to actually access javascript on the webpage.
is it possible with an acceptable amount of work/explanation?  is there a working example somewhere?
it is not a crucial short-term-requirement for the test, so i might as well wait for the htmlunit solution if that can be expected within a reasonable time, but if i could solve it now, i'd certainly be very happy to.

thanks very much

christian

Marc Guillemot wrote:

Hi Christian,

1. yes

2. in a first time this is an htmlunit issue. There is no "plan" just
waiting that someone proposes a good patch.
Then it needs to be usable from WebTest. For onblur it would be
transparent in most of the cases. For keyup webtest would need an
additional way to say that key have been pressed.

3. it depends a bit from what your handlers are doing.

Marc.

bat wrote:
> hello,
>
> from the corresponding forum entries i take it that neither onblur nor
> onkeyup are supported by webtest at this time.
>
> 1. is this correct?
> 2. are there any plans to include support for these events in the future?
> 3. is there any workaround for that right now?
>
> thanks a lot for your help
> christian

_______________________________________________
WebTest mailing list
[e-mail]
http://lists.canoo.com/mailman/listinfo/webtest

[Marc Guillemot]

Hi,

<groovy>
def jsIntrusion = "check('some value')"
def page = step.context.currentResponse
page.executeJavaScriptIfPossible(jsIntrusion, "intrusion code", false, null)
</groovy>

but take care to this note from executeJavaScriptIfPossible's javadoc:
-------------
Please note: Although this method is public, it is not intended for
general execution of javascript. Users of HtmlUnit should interact with
the pages as a user would by clicking on buttons or links and having the
javascript event handlers execute as needed..
-------------

So you may find a workaround this way but the safer way would surely be
to submit a patch allowing htmlunit/webtest to handle these events
natively ;-)

Marc.

bat wrote:

> hi,
>
> i have an input field which calls a javascript function upon onblur/onkeyup
> that does a check on the content of the specified textbox.
> under certain conditions, a message is to be displayed by changing the
> visibility and innerText-property of another html element.
>
> so what's going on is basically the following:
> -----------------------------------------------------------
> application_behaviour.js:
> var myrules = {
> //...
> '#txtInput' : function( element )
> {
>   element.onblur = function()
>   {
>      //...
>      check( this.value );
>   }
>  //...
>   element.onkeyup  = function()
>   {
>     //...
>     check( this.value );
>   }
>   //..
> };
> Behaviour.register(myrules);
> -----------------------------------------------------------
>
> -----------------------------------------------------------
> page.html:
> function check(value)
> {
>   //...
>   document.getElementById(id).innerHTML = someText;
>   document.getElementById(div1).style.visibility = "visible";
>   document.getElementById(div2).style.visibility = "visible";
> }
> -----------------------------------------------------------
>
> i have experimented a bit with <scriptStep>, but that doesn't seem to work.
> apparantly for the same reason you mentioned
> http://www.nabble.com/calling-javascript-functions-tf1402316.html#a3804736
> here :
>
> "there is a fundamental misunderstanding with the <scriptStep>: it allows to
> script webtest and ant, not to run script in the current page.
> You can use <scriptStep> as well as <groovy> to script webtest and through
> webtest you can access the current page and start the execution of a
> javascript script in it. You have to look a the API of webtest and htmlunit
> for it. There is currently no special documentation for it as the right way
> would be to write a special step first not the doc for the hack."
>
> unfortunately i cannot figure out how to actually access javascript on the
> webpage.
> is it possible with an acceptable amount of work/explanation?  is there a
> working example somewhere?
> it is not a crucial short-term-requirement for the test, so i might as well
> wait for the htmlunit solution if that can be expected within a reasonable
> time, but if i could solve it now, i'd certainly be very happy to.
>
> thanks very much
>
> christian
>
>
>
> Marc Guillemot wrote:
>> Hi Christian,
>>
>> 1. yes
>>
>> 2. in a first time this is an htmlunit issue. There is no "plan" just
>> waiting that someone proposes a good patch.
>> Then it needs to be usable from WebTest. For onblur it would be
>> transparent in most of the cases. For keyup webtest would need an
>> additional way to say that key have been pressed.
>>
>> 3. it depends a bit from what your handlers are doing.
>>
>> Marc.
>>
>> bat wrote:
>>> hello,
>>>
>>> from the corresponding forum entries i take it that neither onblur nor
>>> onkeyup are supported by webtest at this time.
>>>
>>> 1. is this correct?
>>> 2. are there any plans to include support for these events in the future?
>>> 3. is there any workaround for that right now?
>>>
>>> thanks a lot for your help
>>> christian
>> _______________________________________________
>> WebTest mailing list
>> WebTest@...
>> http://lists.canoo.com/mailman/listinfo/webtest
>>
>>
>

_______________________________________________
WebTest mailing list
WebTest@...
http://lists.canoo.com/mailman/listinfo/webtest

[bat]

hi marc,

i'm afraid i don't have the skills to fix the problem ;-)

but i've taken a cursory glance at the htmlunit site and i was quite surprised to read this:
"Some event handlers are already implemented and will be triggered at the appropriate time (see table below).
...
onblur: The method WebClient.moveFocusToElement(...) will change the focus to the appropriate element. This event will be triggered when an element loses focus."

it must be a misunderstanding on my part, but that statement leaves me rather confused.

greetings

christian

So you may find a workaround this way but the safer way would surely be
to submit a patch allowing htmlunit/webtest to handle these events
natively ;-)

[Paul King]

I am sure Marc will step in if I get this slightly wrong
but my understanding is that:

onkeyup has 'hooks' in place within htmlunit but no implementation
(and nothing within webtest)

onblur has 'hooks' and an implementation within htmlunit but nothing
at all in webtest

A question I have with many of these events and how they would look
within WebTest is what granularity do people want to support.
The easiest hook would be to cause setInputField to trigger some events
but that doesn't match exactly what a browser would do. In a browser
you would get events for each keystroke as you typed it. Whereas
in the simplest form we would be just having one lot of events
for all the keystrokes.

We could of course add a <sendKeyStroke> or <addKeyStrokeToField>
step but we would need to make it clear that these weren't used
for testing normal form functionality but just browser js functionality.

Cheers, Paul.

bat wrote:

> hi marc,
>
> i'm afraid i don't have the skills to fix the problem ;-)
>
> but i've taken a cursory glance at the
> http://htmlunit.sourceforge.net/javascript-howto.html htmlunit site  and i
> was quite surprised to read this:
> "Some event handlers are already implemented and will be triggered at the
> appropriate time (see table below).
> ...
> onblur: The method WebClient.moveFocusToElement(...) will change the focus
> to the appropriate element. This event will be triggered when an element
> loses focus."
>
> it must be a misunderstanding on my part, but that statement leaves me
> rather confused.
>
> greetings
>
> christian
>
>
>
>> So you may find a workaround this way but the safer way would surely be
>> to submit a patch allowing htmlunit/webtest to handle these events
>> natively ;-)
>>

_______________________________________________
WebTest mailing list
WebTest@...
http://lists.canoo.com/mailman/listinfo/webtest

[Marc Guillemot]

Hi Christian,

this part of htmlunit has been incorrectly implemented: the method
should not be on the WebClient but on a HtmlPage.
Nevertheless WebTest could probably already make use of it calling
moveFocusToElement when executing an action step (setXXX, clickXxx).
Perhaps could you open a WebTest issue with a minimal example (both html
and webtest script) what would allow to integrate such a test in
WebTest's selftests.

Marc.

bat wrote:

> hi marc,
>
> i'm afraid i don't have the skills to fix the problem ;-)
>
> but i've taken a cursory glance at the
> http://htmlunit.sourceforge.net/javascript-howto.html htmlunit site  and i
> was quite surprised to read this:
> "Some event handlers are already implemented and will be triggered at the
> appropriate time (see table below).
> ...
> onblur: The method WebClient.moveFocusToElement(...) will change the focus
> to the appropriate element. This event will be triggered when an element
> loses focus."
>
> it must be a misunderstanding on my part, but that statement leaves me
> rather confused.
>
> greetings
>
> christian
>
>
>
>> So you may find a workaround this way but the safer way would surely be
>> to submit a patch allowing htmlunit/webtest to handle these events
>> natively ;-)
>>

_______________________________________________
WebTest mailing list
WebTest@...
http://lists.canoo.com/mailman/listinfo/webtest

[Marc Guillemot]

Hi Paul & Christian,

Paul explainations are ok for me.

I think that onblur could and should be handled transparently.

Concerning keys events, I see the necessity of an additional steps only
to generate events outside form fields. For form fields I think that it
would be nicer to have an additional optional attribute to determine how
a field is set. For instance with <setInputField text="foo".../>, the
text can be:
1- typed on the keyboard
2- paste with keyboard shortcut
3- paste with mouse menu
4- other way?
I could imagine a "mode" attribute (other propositions are welcome)
which would say how the value is set. In the case of typed text this
should ideally generates the whole key down, key up, key pressed events
sequence.

Marc.

Paul King wrote:

>
> I am sure Marc will step in if I get this slightly wrong
> but my understanding is that:
>
> onkeyup has 'hooks' in place within htmlunit but no implementation
> (and nothing within webtest)
>
> onblur has 'hooks' and an implementation within htmlunit but nothing
> at all in webtest
>
> A question I have with many of these events and how they would look
> within WebTest is what granularity do people want to support.
> The easiest hook would be to cause setInputField to trigger some events
> but that doesn't match exactly what a browser would do. In a browser
> you would get events for each keystroke as you typed it. Whereas
> in the simplest form we would be just having one lot of events
> for all the keystrokes.
>
> We could of course add a <sendKeyStroke> or <addKeyStrokeToField>
> step but we would need to make it clear that these weren't used
> for testing normal form functionality but just browser js functionality.
>
> Cheers, Paul.
>
> bat wrote:
>> hi marc,
>>
>> i'm afraid i don't have the skills to fix the problem ;-)
>>
>> but i've taken a cursory glance at the
>> http://htmlunit.sourceforge.net/javascript-howto.html htmlunit site  
>> and i
>> was quite surprised to read this:
>> "Some event handlers are already implemented and will be triggered at the
>> appropriate time (see table below).
>> ...
>> onblur: The method WebClient.moveFocusToElement(...) will change the
>> focus
>> to the appropriate element. This event will be triggered when an element
>> loses focus."
>>
>> it must be a misunderstanding on my part, but that statement leaves me
>> rather confused.
>>
>> greetings
>>
>> christian
>>
>>
>>
>>> So you may find a workaround this way but the safer way would surely
>>> be to submit a patch allowing htmlunit/webtest to handle these events
>>> natively ;-)
>>>
>
> _______________________________________________
> WebTest mailing list
> WebTest@...
> http://lists.canoo.com/mailman/listinfo/webtest
>

_______________________________________________
WebTest mailing list
WebTest@...
http://lists.canoo.com/mailman/listinfo/webtest