Mouse Pointer Location

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • punkin

    Mouse Pointer Location

    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 programmaticall y, 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:


    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="JavaS cript">
    <!--

    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(l oopid);

    document.onclic k = null;
    document.onmous emove = null;

    clickStarted = false;

    return true;
    }

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

    if (document.layer s) {
    document.f.mX.v alue = e.pageX;
    document.f.mY.v alue = e.pageY;
    }
    else {
    document.f.mX.v alue = e.clientX;
    document.f.mY.v alue = e.clientY;
    }
    }

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

    if (document.layer s) {
    document.f.mous eX.value = e.pageX;
    document.f.mous eY.value = e.pageY;
    }
    else {
    document.f.mous eX.value = e.clientX;
    document.f.mous eY.value = e.clientY;
    }

    return true;
    }

    function init() {
    clickStarted = false;
    document.onmous emove = trackMove;
    if (document.layer s) {
    document.captur eEvents(Event.M OUSEMOVE);
    }
    }

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

    document.onclic k = trackClick;
    if (document.layer s) {
    document.captur eEvents(Event.C LICK);
    }

    clickStarted = true;

    return fireClickEvent( );
    }

    function fireClickEvent( ) {
    if (document.all) { // IEs
    loopid = setInterval("do cument.fireEven t('onclick');", 100);
    }
    else if (document.layer s) { // NS4
    document.f.btnS tart.onclick = trackClick;
    loopid = setInterval("do cument.f.btnSta rt.click();", 100);
    }
    else if (document.imple mentation.hasFe ature("MouseEve nts", "2.0"))
    {
    if (typeof(evt) == "undefined" ) {
    // create an document event.
    evt = document.create Event("MouseEve nts");
    }

    // initialize the event before first dispatching
    evt.initMouseEv ent(
    "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.addEve ntListener("pus h", trackClick, true);
    loopid = setInterval("di spatchClickEven t(evt, document)", 100);
    //dispatchClickEv ent(evt, document); // testing purpose.
    }

    return true;
    }

    function dispatchClickEv ent(evt, evtTarget) {
    evtTarget.dispa tchEvent(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="cleanu p()"><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="startC apturing();"><b r>

    </form>

    </body>
    </html>
  • Richard Cornford

    #2
    Re: Mouse Pointer Location

    "punkin" <mclai@mail.com > wrote in message
    news:5440be8c.0 309191000.1f75e 50@posting.goog le.com...[color=blue]
    >I am trying to catch mouse position on the entire screen by
    >dynamically generating mouse click event at every 100 ms.[/color]

    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.
    [color=blue]
    >My code only works for IEs but not any Netscape
    >or Gecko-based browsers.[/color]

    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>[color=blue]
    >... . 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.[/color]

    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.onmous emove 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.c om search for
    onmousemove code).

    <snip>[color=blue]
    > function trackMove(e) {
    > if (arguments.leng th == 0) e = event;[/color]

    e = e || event;
    - or -
    e = (e)?e:event;
    - or -
    if(!e)e = event;
    [color=blue]
    > if (document.layer s) {
    > document.f.mX.v alue = e.pageX;
    > document.f.mY.v alue = e.pageY;[/color]
    <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.mous eX.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.


    Comment

    • punkin

      #3
      Re: Mouse Pointer Location

      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.onmous emove 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.lengt h 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@litote s.demon.co.uk> wrote in message news:<bkhkpq$kh 9$1$830fa7a5@ne ws.demon.co.uk> ...[color=blue]
      > "punkin" <mclai@mail.com > wrote in message
      > news:5440be8c.0 309191000.1f75e 50@posting.goog le.com...[color=green]
      > >I am trying to catch mouse position on the entire screen by
      > >dynamically generating mouse click event at every 100 ms.[/color]
      >
      > 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.
      >[color=green]
      > >My code only works for IEs but not any Netscape
      > >or Gecko-based browsers.[/color]
      >
      > 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>[color=green]
      > >... . 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.[/color]
      >
      > 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.onmous emove 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.c om search for
      > onmousemove code).
      >
      > <snip>[color=green]
      > > function trackMove(e) {
      > > if (arguments.leng th == 0) e = event;[/color]
      >
      > e = e || event;
      > - or -
      > e = (e)?e:event;
      > - or -
      > if(!e)e = event;
      >[color=green]
      > > if (document.layer s) {
      > > document.f.mX.v alue = e.pageX;
      > > document.f.mY.v alue = e.pageY;[/color]
      > <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.mous eX.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.[/color]

      Comment

      • Lasse Reichstein Nielsen

        #4
        Re: Mouse Pointer Location

        mclai@mail.com (punkin) writes:
        [color=blue]
        > Yes, I am checking the mouse position on the entire screen regardless
        > of the mouse on the browser window.[/color]

        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.
        [color=blue]
        > 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.[/color]

        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.
        [color=blue]
        > FYI, the purpose of checking document.layers is to see if the browser
        > is NN4.x.[/color]

        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.
        [color=blue]
        > The code you see is just for testing purpose. They are absolutely
        > correct.[/color]

        Ah, testing code. So we should not expect it to be absolutely correct
        on all browsers, just the ones being tested.
        [color=blue]
        > 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.[/color]

        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).
        [color=blue]
        > I will be checking the arguments.lengt h anyway[/color]

        arguments.lengt h
        and
        (e?1:0)
        are comletely equvialent for an event handler, unless you call the
        function yourself also.
        [color=blue]
        > Otherwise, I will tell the same to my clients - mission impossible -
        > it is really a techical issue.[/color]

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

        Comment

        • Ivo

          #5
          Re: Mouse Pointer Location

          "Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
          news:vfrmjrbh.f sf@hotpop.com.. .[color=blue]
          > mclai@mail.com (punkin) writes:
          >[color=green]
          > > Yes, I am checking the mouse position on the entire screen regardless
          > > of the mouse on the browser window.[/color]
          >
          > 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.
          >[color=green]
          > > 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.[/color]
          >
          > 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.[/color]

          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


          Comment

          • Richard Cornford

            #6
            Re: Mouse Pointer Location

            "Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
            news:vfrmjrbh.f sf@hotpop.com.. .[color=blue]
            > mclai@mail.com (punkin) writes:
            >[color=green]
            >>Yes, I am checking the mouse position on the entire screen
            >>regardless of the mouse on the browser window.[/color]
            >
            >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.[/color]
            <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.


            Comment

            • Jim Ley

              #7
              Re: Mouse Pointer Location

              On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
              <Richard@litote s.demon.co.uk> wrote:
              [color=blue]
              >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?[/color]

              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.javas cript FAQ - http://jibbering.com/faq/

              Comment

              • Richard Cornford

                #8
                Re: Mouse Pointer Location

                "Jim Ley" <jim@jibbering. com> wrote in message
                news:3f6db1f1.1 3526059@news.ci s.dfn.de...[color=blue]
                >On Sun, 21 Sep 2003 14:37:25 +0100, "Richard Cornford"
                ><Richard@litot es.demon.co.uk> wrote:
                >[color=green]
                >>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?[/color]
                >
                >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.[/color]

                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.


                Comment

                • Lasse Reichstein Nielsen

                  #9
                  Re: Mouse Pointer Location

                  "Richard Cornford" <Richard@litote s.demon.co.uk> writes:
                  [color=blue]
                  > I am not so sure that there is a security issue here.[/color]

                  Not being sure there isn't, is a sufficent reason to be careful.
                  [color=blue]
                  > What can you learn from knowing where the mouse is when it is not
                  > over the viewport?[/color]

                  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.cryptomathi c.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.ht ml>).

                  A browser page is untrusted code. It should not have unchecked access
                  to *anything* outside of itself, if it can be avoided.
                  [color=blue]
                  > 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).[/color]

                  So only some people will be vulnerable. It is still a problem.
                  [color=blue]
                  > 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.[/color]

                  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.
                  [color=blue]
                  > 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.[/color]

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

                  Comment

                  • Dr John Stockton

                    #10
                    Re: Mouse Pointer Location

                    JRS: In article <bkkart$sg$1$83 02bc10@news.dem on.co.uk>, seen in
                    news:comp.lang. javascript, Richard Cornford
                    <Richard@litote s.demon.co.uk> posted at Sun, 21 Sep 2003 14:37:25 :-[color=blue]
                    >"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
                    >news:vfrmjrbh. fsf@hotpop.com. ..[color=green]
                    >> mclai@mail.com (punkin) writes:
                    >>[color=darkred]
                    >>>Yes, I am checking the mouse position on the entire screen
                    >>>regardless of the mouse on the browser window.[/color]
                    >>
                    >>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.[/color]
                    ><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.[/color]


                    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.demo n.co.uk/js-index.htm> JS maths, dates, sources.
                    <URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

                    Comment

                    Working...