By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,903 Members | 1,677 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,903 IT Pros & Developers. It's quick & easy.

Mouse Pointer Location

P: n/a
I am trying to catch mouse position on the entire screen by
dynamically generating mouse click event at every 100 ms. My code
only works for IEs but not any Netscape or Gecko-based browsers. The
following are the problems and I hope that there is someone who can
enlighten me or give me some pointers. Also, my testing code is
attached at the end. And please don't ask me why I am doing this - it
is one of functional requirements by all means that I don't know how
to explain.

For NN4.x:

Since NN4.x doesn't support document.click(), I use the button click()
instead. I am sure that the click event is generated every 100 ms but
the mouse position is never captured. [x,y] are always [0,0] unless
it is a physical click by the mouse device.

For NN6.x and Gecko-based browsers:

In order to dispatch the event programmatically, I first created an
MouseEvent, initialized it and then dispatched it at every 100 ms.
Unfortunately, I have the same result as NN4.x: [x,y] are always [0,0]
unless it is a physical click by the mouse device. Then, I tried to
play around with the event type argument being set in
initMouseEvent(). I changed the event type from "click" to "push".
In this case, I added an event listener to listen to this PUSH event.
The result remains unchanged. I also tried to change the press count
from 1 to 0. It is also in vain too.

I've read through the W3C DOM 2 Event document:
http://www.w3.org/TR/DOM-Level-2-Eve...ts-EventTarget

but I still have no clue to proceed this: capture the mouse positions
on the entire screen. I really hope that there is someone who can
help me out and give me some pointers of it. Hopefully, it is not a
mission impossible. Thanks. The following is my testing code for
reference.
<html>
<head>
<title></title>

<script type="text/JavaScript" language="JavaScript">
<!--

window.onerror = function(mesg, url, line) {
alert("error: [line " + line +"]: " + mesg + "\n" + url);
return cleanup();
}

window.onunload = cleanup;

function cleanup(e) {
if (typeof(loopid) != "undefined")
clearInterval(loopid);

document.onclick = null;
document.onmousemove = null;

clickStarted = false;

return true;
}

function trackMove(e) {
if (arguments.length == 0) e = event;

if (document.layers) {
document.f.mX.value = e.pageX;
document.f.mY.value = e.pageY;
}
else {
document.f.mX.value = e.clientX;
document.f.mY.value = e.clientY;
}
}

function trackClick(e) {
if (arguments.length == 0) e = event;

if (document.layers) {
document.f.mouseX.value = e.pageX;
document.f.mouseY.value = e.pageY;
}
else {
document.f.mouseX.value = e.clientX;
document.f.mouseY.value = e.clientY;
}

return true;
}

function init() {
clickStarted = false;
document.onmousemove = trackMove;
if (document.layers) {
document.captureEvents(Event.MOUSEMOVE);
}
}

function startCapturing(e) {
if (clickStarted) {
alert("Already started!");
return true;
}

document.onclick = trackClick;
if (document.layers) {
document.captureEvents(Event.CLICK);
}

clickStarted = true;

return fireClickEvent();
}

function fireClickEvent() {
if (document.all) { // IEs
loopid = setInterval("document.fireEvent('onclick');", 100);
}
else if (document.layers) { // NS4
document.f.btnStart.onclick = trackClick;
loopid = setInterval("document.f.btnStart.click();", 100);
}
else if (document.implementation.hasFeature("MouseEvents", "2.0"))
{
if (typeof(evt) == "undefined") {
// create an document event.
evt = document.createEvent("MouseEvents");
}

// initialize the event before first dispatching
evt.initMouseEvent(
"click", //"push // event type
true,
true,
window,
0, // numbre of times mouse is pressed and released
0,
0,
0,
0,
false,
false,
false,
false,
0,
window
);
//document.addEventListener("push", trackClick, true);
loopid = setInterval("dispatchClickEvent(evt, document)", 100);
//dispatchClickEvent(evt, document); // testing purpose.
}

return true;
}

function dispatchClickEvent(evt, evtTarget) {
evtTarget.dispatchEvent(evt);
}
//-->
</script>
</head>

<body onload="init()">

Click on the document and start tracking.

<form name="f">
<input type="button" id="btnCancel" name="btnCancel"
value=" Click Me to Stop Mouse Tracking "
onclick="cleanup()"><br>
<br><br>
MouseMove X: <input type="text" name="mX" value="0" size="4"><br>
MouseMove Y: <input type="text" name="mY" value="0" size="4"><br>
<br><br>
Click X: <input type="text" name="mouseX" value="0" size="4"><br>
Click Y: <input type="text" name="mouseY" value="0" size="4"><br>
<br><br>
<input type="button" id="btnStart" name="btnStart"
value="Start Click Tracking"
onclick="startCapturing();"><br>

</form>

</body>
</html>
Jul 20 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
"punkin" <mc***@mail.com> wrote in message
news:54*************************@posting.google.co m...
I am trying to catch mouse position on the entire screen by
dynamically generating mouse click event at every 100 ms.
Do you mean "screen" or are you actually just trying to monitor the
position of the mouse in the window's viewport or on the HTML page? I
don't see any references to screenX/Y event properties in the code below
so I think that you cannot mean that want to know the mouse position on
the screen. It is important to recognise the distinction between the
user's screen (desktop or whatever) and the browser window.
My code only works for IEs but not any Netscape
or Gecko-based browsers.
I don't think that this approach will work on gecko based browsers
because you are creating your own event objects (initMouseEvent) and for
that you have to provide the mouse XY co-ordinates for the new event
object yourself.

<snip>... . And please don't ask me why I am doing this - it
is one of functional requirements by all means that I
don't know how to explain.
There is a close relationship between your understanding of something
and your ability to explain it. Trying to explain things will often make
they clearer in your mind so it is worth the effort for that reason
alone but in newsgroup postings it is always worth explaining why. Why
allows respondents to propose complete alternatives instead of
concentrating on trying to fix one approach that may just be
fundamentally flawed from the outset.

If I wanted to track mouse position for either the viewport or (more
likely) the HTML page I would use the document.onmousemove events as a
source of that information. But as you will not say why you want to do
this I cannot tell if that is appropriate so it is not worth my going
into details as to how (though you might groups.google.com search for
onmousemove code).

<snip> function trackMove(e) {
if (arguments.length == 0) e = event;
e = e || event;
- or -
e = (e)?e:event;
- or -
if(!e)e = event;
if (document.layers) {
document.f.mX.value = e.pageX;
document.f.mY.value = e.pageY;

<snip>

This logic is total nonsense and should be avoided. There is no
relationship between a browser implementing a document.layers collection
and reading e.pageX instead of e.clientX. It is an assumption and should
be avoided unless there is absolutly no alternative. In this case a more
useful test would probably be:-

if(typeof e.pageX == 'number'){
document.f.mouseX.value = e.pageX;
}else{
...
}

But pageX/Y and clientX/Y are related but different co-ordinates so on
the face of it I don't see this code as providing useable information
anyway. I would be inclined to normalise one set of co-ordinates so that
the results were either page relative or viewport relative (correcting
for clientTop/Left on IE to remove the (default) 2px offset produced by
the inner viewport borders).

Richard.
Jul 20 '05 #2

P: n/a
Yes, I am checking the mouse position on the entire screen regardless
of the mouse on the browser window. But the coordinations for the X/Y
that I want to get are relative to the HTML page, not the screen. It
will save me a lot of calculation in the next operation. Therefore,
checking clientX/clientY for IEs and newer Gecko-basked browsers (e.g.
NN6+) is correct. However, I don't mind if I can get screenX or
screenY instead if the mouse pointer is returned to me. So the
viewport is not the main problem here.

I cannot disagree with what you thought here: the approach I have may
not be able to detect where the mouse is for all browsers. It may
only work for IEs because IE is integrated with its own operating
system - Windows. I have read a lot of OS/browser specifications
lately with regards to the mouse pointer detection. But I am just
afraid to conclude this to myself. The clients won't listen to what I
said without trying. They believe that it works for IEs; there must
be a way to work for other browsers. Sometimes I just don't know how
to explain to them at all.

I appreciate your comment on the suggestion by using
document.onmousemove but if you look at my code carefully or running
it on your own, checking onmousemove event won't be my solution. I
have no problem doing this and get my results back from all supported
browsers. However, it is not what my clients want.

FYI, the purpose of checking document.layers is to see if the browser
is NN4.x. It is very important when you develop a cross-browser page
unless you don't support it. After having done this, I will also need
to create a layer dynamically in NN4.x for further operations. The
code you see is just for testing purpose. They are absolutely
correct. What you suggest here is just syntactically sugar.

I also thank for another comment about the "e" but I will stick with
mine. Because mine will make more sense in the future development
when the event handler is getting more complicated. I will be
checking the arguments.length anyway regardless of that the mouse
position can be detected dynamically on the screen. All my code
posted here is just for one single purpose: detect the mouse position
on the screen regardless of the viewpoint.

I have done my research before I was posting this to the group. The
question looks like simple but it isn't. I just hope that there is
someone who is really able to answer or give me some hint. Otherwise,
I will tell the same to my clients - mission impossible - it is really
a techical issue.

Thanks for taking your time to answer my question.

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<bk*******************@news.demon.co.uk>...
"punkin" <mc***@mail.com> wrote in message
news:54*************************@posting.google.co m...
I am trying to catch mouse position on the entire screen by
dynamically generating mouse click event at every 100 ms.


Do you mean "screen" or are you actually just trying to monitor the
position of the mouse in the window's viewport or on the HTML page? I
don't see any references to screenX/Y event properties in the code below
so I think that you cannot mean that want to know the mouse position on
the screen. It is important to recognise the distinction between the
user's screen (desktop or whatever) and the browser window.
My code only works for IEs but not any Netscape
or Gecko-based browsers.


I don't think that this approach will work on gecko based browsers
because you are creating your own event objects (initMouseEvent) and for
that you have to provide the mouse XY co-ordinates for the new event
object yourself.

<snip>
... . And please don't ask me why I am doing this - it
is one of functional requirements by all means that I
don't know how to explain.


There is a close relationship between your understanding of something
and your ability to explain it. Trying to explain things will often make
they clearer in your mind so it is worth the effort for that reason
alone but in newsgroup postings it is always worth explaining why. Why
allows respondents to propose complete alternatives instead of
concentrating on trying to fix one approach that may just be
fundamentally flawed from the outset.

If I wanted to track mouse position for either the viewport or (more
likely) the HTML page I would use the document.onmousemove events as a
source of that information. But as you will not say why you want to do
this I cannot tell if that is appropriate so it is not worth my going
into details as to how (though you might groups.google.com search for
onmousemove code).

<snip>
function trackMove(e) {
if (arguments.length == 0) e = event;


e = e || event;
- or -
e = (e)?e:event;
- or -
if(!e)e = event;
if (document.layers) {
document.f.mX.value = e.pageX;
document.f.mY.value = e.pageY;

<snip>

This logic is total nonsense and should be avoided. There is no
relationship between a browser implementing a document.layers collection
and reading e.pageX instead of e.clientX. It is an assumption and should
be avoided unless there is absolutly no alternative. In this case a more
useful test would probably be:-

if(typeof e.pageX == 'number'){
document.f.mouseX.value = e.pageX;
}else{
...
}

But pageX/Y and clientX/Y are related but different co-ordinates so on
the face of it I don't see this code as providing useable information
anyway. I would be inclined to normalise one set of co-ordinates so that
the results were either page relative or viewport relative (correcting
for clientTop/Left on IE to remove the (default) 2px offset produced by
the inner viewport borders).

Richard.

Jul 20 '05 #3

P: n/a
mc***@mail.com (punkin) writes:
Yes, I am checking the mouse position on the entire screen regardless
of the mouse on the browser window.
It is scary that it is even possible in some browsers. I am pretty
sure that, e.g., Opera would consider it a security flaw and fix it,
so I would not expect it to work in all browsers.
The clients won't listen to what I said without trying. They believe
that it works for IEs; there must be a way to work for other
browsers. Sometimes I just don't know how to explain to them at all.
I would say that other browsers consider it a security issue.

Would you be able to capture the mouse position over another browser
window, containing a document from another domain? That sounds
dangerous too.
FYI, the purpose of checking document.layers is to see if the browser
is NN4.x.
That fails on OmniWeb, which has a document.layers property but isn't
Netscape 4. It fails to recognize Mozilla/Netscape 6+ which doesn't have
document.layers, but which does support event.pageX.

It is generally recommended to check for the properties you need, not
other properties that are believed to be correlated with them.
The code you see is just for testing purpose. They are absolutely
correct.
Ah, testing code. So we should not expect it to be absolutely correct
on all browsers, just the ones being tested.
I also thank for another comment about the "e" but I will stick with
mine. Because mine will make more sense in the future development
when the event handler is getting more complicated.
The event handler will still only receive zero or one arguments. If it
receives one, the variable e will be an object, otherwise it will be
undefined. As such, the different methods are equivalent, unless the
browser is so old that it doesn't have a local arguments variable
(Netscape 2 or IE 2, so probably not relevant).
I will be checking the arguments.length anyway
arguments.length
and
(e?1:0)
are comletely equvialent for an event handler, unless you call the
function yourself also.
Otherwise, I will tell the same to my clients - mission impossible -
it is really a techical issue.


If you find a way to do what you want in Opera, please tell us. I will
bug-report it :)

(And please trim your quotes)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #4

P: n/a
Ivo
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:vf**********@hotpop.com...
mc***@mail.com (punkin) writes:
Yes, I am checking the mouse position on the entire screen regardless
of the mouse on the browser window.


It is scary that it is even possible in some browsers. I am pretty
sure that, e.g., Opera would consider it a security flaw and fix it,
so I would not expect it to work in all browsers.
The clients won't listen to what I said without trying. They believe
that it works for IEs; there must be a way to work for other
browsers. Sometimes I just don't know how to explain to them at all.


I would say that other browsers consider it a security issue.

Would you be able to capture the mouse position over another browser
window, containing a document from another domain? That sounds
dangerous too.


I was happily multitasking away last week, having IE, a few Notepads, Excel,
Paint Shop, WinAmp and some other windows and programs running, when a
strange sound caught my attention, the short, clear sort of sound usually
used for mouseovers. Notepad is not known for its fancy audio enhancements,
so I was puzzled. I couldn't find the cause until I realized that a Flash
file in one of the IE windows had finished loading, and was making beeps
when my mouse hovered over its buttons, even though there were three other
windows and two other programs in between.
Ivo
Jul 20 '05 #5

P: n/a
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:vf**********@hotpop.com...
mc***@mail.com (punkin) writes:
Yes, I am checking the mouse position on the entire screen
regardless of the mouse on the browser window.


It is scary that it is even possible in some browsers. I am
pretty sure that, e.g., Opera would consider it a security
flaw and fix it, so I would not expect it to work in all
browsers.

<snip>

I am not so sure that there is a security issue here. What can you learn
from knowing where the mouse is when it is not over the viewport? You
don't know where the user has positioned their other windows (or, as Ivo
points out, how they are stacked), the position/size/etc of the taskbar,
the position/size/etc of desktop icons or even the
position/size/distribution/etc of chrome in the browser window around
the viewport. All are subject to user modification and vary by OS/OS
version/Window manager anyway.

There is also little that can be done with a mouse (assuming that the
pointing device is a mouse/trackball and not a pen/touchpad/etc that
will just not provide continuous position information) that cannot be
done from a keyboard (or with menus). So even if the desire is to do the
impossible and monitor back, refresh and close button activity, knowing
that the mouse was over the back button when an unload event happens
would not mean that the back button had been used to navigate the page.
It could just have easily been Alt+F4 that triggered the unload event,
or any number of other things.

It sounds like an effort to solve the wrong problem, but I don't think
that we are going to find out why this is being attempted so the real
solution will probably not be presented.

Richard.
Jul 20 '05 #6

P: n/a
On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
I am not so sure that there is a security issue here. What can you learn
from knowing where the mouse is when it is not over the viewport?


You can position a window or other component underneath, or keep your
window away from the window, preventing the user from closing (with
the mouse) or otherwise interacting with the content - of course
there's still other re-courses, but not everyone knows them.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #7

P: n/a
"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f***************@news.cis.dfn.de...
On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
I am not so sure that there is a security issue here. What
can you learn from knowing where the mouse is when it is
not over the viewport?


You can position a window or other component underneath, or
keep your window away from the window, preventing the user
from closing (with the mouse) or otherwise interacting with
the content - of course there's still other re-courses, but
not everyone knows them.


An aggressively anti-social script, itís a possibility. Baring knowledge
if anything more efficient I am sure any user can work out how to shut
their computer down.

I have often thought that browsers should be equipped with an
anti-bookmark facility where users could instantly instruct their
browser to record the current domain and then never make a request to
that domain ever again (and therefor the option to import other people's
black-lists).

It might be good if such a facility was scriptable. Not that any site
would want to call a function that resulted in it black-listing itself
but content inserting/re-writing proxies could be configured to detect
anti-social scripts and insert a blacklisting script in its place.
Rendering such activity as resizing/repositioning windows not only
unreliable but potentially positively harmful for the sight in question.

Richard.
Jul 20 '05 #8

P: n/a
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
I am not so sure that there is a security issue here.
Not being sure there isn't, is a sufficent reason to be careful.
What can you learn from knowing where the mouse is when it is not
over the viewport?
We are used to considering all possible users in this group, and
rejecting an idea if it fails to work in (almost) all cases. Security
works the opposite way. If there is a way to abuse something, even for
only a small percentage of the IE users, say those on Windows 2K with
Office 97 installed, and only on Thursdays, it is still a security
issue.

One, potential, problem I can think of is a graphical password entry
program like this
<URL:http://www.cryptomathic.dk/secure-memorizer/index.html>. You
enter a passkey by clicking on different nodes or areas of a graph. It
is currently, only used in their Palm software (and is a pretty neat
idea, actually), but I could see it used on PC's too. If that happens,
a malicious page could redirect you to a passkey entry page, even one
submitted over https, and snoop the mouse movement. That will give
lots of data that can be used to crack the key, probably significantly
faster than a brute force attack.

And how about disabled users entering passwords with an on-screen
keyboard? "We will send this free pr0n picture to your Hotmail account.
Just enter your e-mail address, and log in to Hotmail in the window
that opens."

If experience have taught os anything about security, it is that we
cannot predict what seemingly insignificant details will be abusable
in the future (<URL:http://www.counterpane.com/side_channel.html>).

A browser page is untrusted code. It should not have unchecked access
to *anything* outside of itself, if it can be avoided.
There is also little that can be done with a mouse (assuming that the
pointing device is a mouse/trackball and not a pen/touchpad/etc that
will just not provide continuous position information) that cannot be
done from a keyboard (or with menus).
So only some people will be vulnerable. It is still a problem.
So even if the desire is to do the impossible and monitor back,
refresh and close button activity, knowing that the mouse was over
the back button when an unload event happens would not mean that the
back button had been used to navigate the page. It could just have
easily been Alt+F4 that triggered the unload event, or any number of
other things.
You are still trying to find examples where abusive behavior can fail,
and obviosuly there are plently.
It is a security problem if it can succeede at all, with anything more
than negligable probability.
It sounds like an effort to solve the wrong problem, but I don't think
that we are going to find out why this is being attempted so the real
solution will probably not be presented.


I agree on that. It just bothers me that it is possible in any browser,
and especially in the most widely used browser.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #9

P: n/a
JRS: In article <bk******************@news.demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted at Sun, 21 Sep 2003 14:37:25 :-
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:vf**********@hotpop.com...
mc***@mail.com (punkin) writes:
Yes, I am checking the mouse position on the entire screen
regardless of the mouse on the browser window.


It is scary that it is even possible in some browsers. I am
pretty sure that, e.g., Opera would consider it a security
flaw and fix it, so I would not expect it to work in all
browsers.

<snip>

I am not so sure that there is a security issue here. What can you learn
from knowing where the mouse is when it is not over the viewport? You
don't know where the user has positioned their other windows (or, as Ivo
points out, how they are stacked), the position/size/etc of the taskbar,
the position/size/etc of desktop icons or even the
position/size/distribution/etc of chrome in the browser window around
the viewport. All are subject to user modification and vary by OS/OS
version/Window manager anyway.

A system should mot be given any more capabilities than are proper for
its needs. You, I, and the browser writers may not see this as
exploitable; but some ingenious person might. All that it seems proper
for a window to know is the position of the mouse within it, or that it
is outside (and, possibly, where it crossed the edge).

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.
Jul 20 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.