Re: Mouse Pointer Location

"punkin" <mclai (AT) mail (DOT) com> wrote

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.

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" <Richard (AT) litotes (DOT) demon.co.uk> wrote

"punkin" <mclai (AT) mail (DOT) com> wrote in message
news:5440be8c.0309191000.1f75e50 (AT) posting (DOT) google.com...
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.

mclai (AT) mail (DOT) 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 - lrn (AT) hotpop (DOT) com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

"Lasse Reichstein Nielsen" <lrn (AT) hotpop (DOT) com> wrote

mclai (AT) mail (DOT) 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

"Lasse Reichstein Nielsen" <lrn (AT) hotpop (DOT) com> wrote

mclai (AT) mail (DOT) 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.

On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
<Richard (AT) litotes (DOT) 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/

"Jim Ley" <jim (AT) jibbering (DOT) com> wrote

On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
Richard (AT) litotes (DOT) 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.

"Richard Cornford" <Richard (AT) litotes (DOT) 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 - lrn (AT) hotpop (DOT) com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

JRS: In article <bkkart$sg$1$8302bc10 (AT) news (DOT) demon.co.uk>, seen in
news:comp.lang.javascript, Richard Cornford
<Richard (AT) litotes (DOT) demon.co.uk> posted at Sun, 21 Sep 2003 14:37:25 :-

"Lasse Reichstein Nielsen" <lrn (AT) hotpop (DOT) com> wrote in message
news:vfrmjrbh.fsf (AT) hotpop (DOT) com...
mclai (AT) mail (DOT) 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.