.click shortcoming?

[Csaba2000]

I'd like to be able to simulate a mouse click on an arbitrary HTML element (for the purpose of invoking whatever
behaviour that element would have, had a real mouse click come to it) so that my click event will contain mouse
coordinates (I only need this for IE 5.5+)

In most cases, if domElem is the element, I can do domElem.click and I get the desired behaviour (e.g. buttons) so I
don't need the mouse coordinates. However, if I have an <input type=image ...> element then the normal behaviour is
to actually send the x and y coordinates to the server when the corresponding form is submitted (Sprint.com uses this
type of button to confirm credit card payments). Doing .click on that element will submit 0 for the x and y
coordinates. So will hitting the space bar when that element has focus (so a non mouse user is effectively barred
from making online payments to Sprint).

Thanks,
Csaba Gabor from New York

I'm actually doing this by means of an external VB/VBScript application that gets ahold of the web page on the
client's (that is my) machine. The point is that my little app is allowed to do things like get references to DOM
elements and invoke their methods.

 

[Hywel Jenkins]

I'd like to be able to simulate a mouse click on an arbitrary HTML element (for the purpose of invoking whatever
behaviour that element would have, had a real mouse click come to it) so that my click event will contain mouse
coordinates (I only need this for IE 5.5+)

In most cases, if domElem is the element, I can do domElem.click and I get the desired behaviour (e.g. buttons) so I
don't need the mouse coordinates. However, if I have an <input type=image ...> element then the normal behaviour is
to actually send the x and y coordinates to the server when the corresponding form is submitted (Sprint.com uses this
type of button to confirm credit card payments). Doing .click on that element will submit 0 for the x and y
coordinates. So will hitting the space bar when that element has focus (so a non mouse user is effectively barred
from making online payments to Sprint).

So what's the shortcoming of .click? Considering you're not actually
clicking the image, how could it possibly determine different x/y
coordinates for you?

Are you sure that hitting space on the input form stops people making
payments to Sprint?

 

[Csaba2000]

I suppose the title could be improved. It's not so much that .click has a shortcoming (I'm happy with .click, though
I was sort of hoping somebody would tell me that it has an optional position argument), but that it is a shortcoming
of IE. For consider, I can simulate the desired click action (to include mouse position) by using windows APIs (from
VB) to set the mouse cursor position (SetCursoPos), then bring IE to the foreground so that it can accept input, and
the simulate the click (by means of mouse_event).

It's this bringing IE to the foreground that bugs me. Why should I have to do that? I can set attributes on all
elements and execute their various methods at will without IE having to be in the user's face. That would be more of
a shortcoming of IE (since everything else I want to do in this vein is doable). The question mark in the title was
because it's such an obvious thing to have that it's more likely me who is missing something (though I don't see any
useful replies so far).

Yes, I am sure about the Sprint issue becuase I have tried to effect making payment by both using the space button at
that point and also by comandeering the IE window at that point and issuing a .click to the input element (and also
tried a .submit to the form). Seems to me that this directly contravenes
http://msdn.microsoft.com/library/d...inui/windowsuserinterface/userinput/mouseinpu
t/aboutmouseinput.asp

Csaba Gabor