Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts

    elementFromPoint substitute for Gecko

    Alright, I've been needing an elementFromPoint lately (for some drag/drop code), and it turns out my old replacement for Gecko was buggy at best. It's getting sort of complicated, so I'm going to post everything that I have/know (and feel free to hop in with suggestions) and at least organize my thoughts:

    • If event.type == "mousemove", then event.explicitOriginalTarget refers to the element at the point (event.clientX, event.clientY). However, it must be a user-initiated event, not a progmatically fired one (through createEvent()). It calls "getTargetFromFrame" (http://lxr.mozilla.org/seamonkey/sou...Event.cpp#123), and I'm assuming that the current frame is only updated for real user-events.

      If there was some way of progmatically firing an event and updating the frame reference, then this would be a solution.
    • Leveraging XUL's "mousethrough" and "allowevents" attributes. When "mousethrough" is set to "always" on a XUL element (<box> for example), mouse events should pass right through the element (just like SVG's pointer-events="none"), so mouseover/mouseout events will fire on elements "under" the current one if you're dynamically dragging some element around the canvas. See http://lxr.mozilla.org/seamonkey/sou...Frame.cpp#1665 for some reading on mousethrough and GetFrameForPoint. "allowevents" either allows events to pass through to children nodes or not... if we set mousethrough to always, then allowevents to false, one would think that mouse events simply would pass right through any content inside the <box>.

      The only problem is, this doesn't seem to work.


    So those are the two approaches I've come up with so far. It wouldn't be terribly difficult to write a C++ patch to expose GetFrameForPoint via document.elementFromPoint, but that wouldn't land until well after Firefox 2, and exclude all prior Gecko releases. Another possibility is mapping the boxObject for every element (document.getBoxObjectFor(element)) and writing a document.elementFromPoint method to search through the box objects, but that is highly inefficient and a last resort. (And I already have an XBL binding which does exactly that, which is attached if you're interested.)

    I'll keep posting on this thread with progress, but if any of you have some particular insights... .
    Attached Files Attached Files

  • #2
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I thought your other earlier posting did come quite close to fully working model.
    http://www.codingforums.com/archive/...p?t-21674.html
    Thought only issues with it were the textboxes/textareas only firing on border enter/out.

  • #3
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    The testing was done off of a mousemove events, so the synthetic event firing I did was left on the same frame that the actual event was over, giving the appearance that it worked.

  • #4
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts
    in simple terms, in a frameset, iframe environment that would not work?

  • #5
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    No no, not frame as in <frame>, but frame as in internal rendering "frame".

  • #6
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts
    great, for others i found this useful
    http://developer.mozilla.org/en/docs...w_Inside_Gecko (to explain frame concept)

    and, i'm all for having this method available in some fashion for all browsers..

    It is highly requested to provide drag-and-drop functionality where elements can respond during the movements, but also very inefficient to implement for all class-A browsers.

    We tend to only poll the available "targets" that can react, and test them for collision(s), but requires a lot of calculations, and must be developer driven through the use of classNames, or other means to create the "target" collection.
    Last edited by KC-Luck; 05-22-2006 at 07:08 PM.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •