Difference between fire_event("click") and element.click

[Angrez Singh]

Hi,

Can some one explain me the difference? In one of our projects if I do link.click() i get javascript errors & if i do link.fire_event("onclick") nothing happens.

- Angrez

[Angrez Singh]

I am facing a weird problem

if I click the link manually then i get the desired results but if I use link.click() then i get javascript errors. Link has href() which points to some javascript method

<a href="javascript:changeSelection()">

Any ideas? or suggestions? to fire the javascript event successfully using watir?

- Angrez

[Paul Rogers]

the javascript is probably needing the event object to work correctly. The dom click method generates a click event, but does not add the associated event object, so it works fine for simple things like <a href='www.google.com'>Google</a>

The fire_event('onClick') does essentially the same thing,

( http://msdn.microsoft.com/en-us/library/ms536913(VS.85).aspx   for onclick event)
( http://msdn.microsoft.com/en-us/library/ms536363(VS.85).aspx   for click method )

for more advanced uses, the event object is used. Ive been trying to get this added to watir but just havent had time. As we get richer user interfaces, especially ones using the common libraries like jquery this is going to become more important.

Paul

[Angrez Singh]

Thanks Paul for the information. Just going through it found that

"If the user clicks an object that can receive the input focus but does not already have the focus, the onfocus event occurs for that object before the onclick event. "

In my case when I used click "onfocus" event was not getting raised. When i explicitly fired "onfocus" event on link and then used link.click() i was able to get the desired results.

My question now is, does watir fires "onfocus" event before clicking an element? If not, then do we need to change it?

- Angrez

[Paul Rogers]

glad I could help!
as to wether it needs to be changed - no idea.

Paul

[Bret Pettichord]

Angrez Singh wrote:
> Thanks Paul for the information. Just going through it found that
>
> "If the user clicks an object that can receive the input focus but
> does not already have the focus, the onfocus

> <http://msdn.microsoft.com/en-us/library/ms536934%28VS.85%29.aspx>
> event occurs for that object before the *onclick* event. "

>
> In my case when I used click "onfocus" event was not getting raised.
> When i explicitly fired "onfocus" event on link and then used
> link.click() i was able to get the desired results.
>
> My question now is, does watir fires "onfocus" event before clicking
> an element? If not, then do we need to change it?

Sounds reasonable.

--
Bret Pettichord
CTO, WatirCraft LLC, www.watircraft.com
Lead Developer, Watir, www.watir.com
Blog, www.io.com/~wazmo/blog
Twitter, www.twitter.com/bpettichord

Watir Training: Portland/Beaverton April 16-17
www.watircraft.com/training

[Jarmo Pertman]

As I understand, then onfocus event is require prior clicking
something? So for example, if uses clicks with mouse, then onfocus
event is triggered before actual click?

Is this the reason, why at the moment I have to do something like this
in my tests to work correctly:
button.click
button.fire_event("onclick")

So, if .click method would do fire_event("onfocus") before clicking
itself, then I wouldn't have to specifically call .fire_event
("onclick") method itself but it would be called like normally happens
with manual interaction?

What about text_field and select_list "onchange" event? It seems that
they aren't triggered by Watir either. At the moment I'm just changing
text_field value and then firing onchange event manually. Why not make
it to trigger automatically also?

Jarmo

[Chuck van der Linden]

On Apr 8, 5:26 am, Jarmo Pertman <Jarm...@gmail.com> wrote:
> As I understand, then onfocus event is require prior clicking
> something? So for example, if uses clicks with mouse, then onfocus
> event is triggered before actual click?

I don't belive it's 'required' or the .click method would not work at
all, and for most of us it works quite well.

Actually I believe that when the user clicks the mouse in the UI there
are a series of events that the browser fires off
focus, mousedown, mouseup, click These are not 'required' they are
merely what happens. how the UI reacts will depend on which of these
methods have been implemented for a given element in the client side
javascript, and/or what kind fo element you are clicking on

There's also I believe a time proximity between the mousedown and
mouseup that is required for an actual click event to be issued.

Brett can correct me if I'm remembering right but I seem to recall he
said that Watir is firing off mouseup when the click method is used.

>
> Is this the reason, why at the moment I have to do something like this
> in my tests to work correctly:
> button.click
> button.fire_event("onclick")
>
> So, if .click method would do fire_event("onfocus") before clicking
> itself, then I wouldn't have to specifically call .fire_event
> ("onclick") method itself but it would be called like normally happens
> with manual interaction?
>
> What about text_field and select_list "onchange" event? It seems that
> they aren't triggered by Watir either. At the moment I'm just changing
> text_field value and then firing onchange event manually. Why not make
> it to trigger automatically also?

Perhaps because a lot of sites don't take any action when the
selection in a selection list is changed, so the code works just fine
in a majority of cases without doing this.

OTOH in terms of fooling the system to think there's really a user out
there at the other end of the mouse, it might not be a bad idea to
consider firing off all the events that would normally happen when a
user manually selects something from a selection list.

[Bret Pettichord]

Jarmo,

Watir should issue the same events as would be generated by a real user.
As we've found one's we missed, we've added them.

We've never systematically identified the events that should be
generated. It would be great if someone would do this.

If Watir is missing specific events, that is a bug. A patch to fix the
events you've found missing would be welcome.

Bret

--