View Full Version : elementFromPoint substitute for Gecko

05-22-2006, 02:11 AM
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/source/content/events/src/nsDOMEvent.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/source/layout/xul/base/src/nsBoxFrame.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... :).

05-22-2006, 04:04 PM
I thought your other earlier posting did come quite close to fully working model. :)
Thought only issues with it were the textboxes/textareas only firing on border enter/out.

05-22-2006, 05:29 PM
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.

05-22-2006, 06:38 PM
in simple terms, in a frameset, iframe environment that would not work?

05-22-2006, 06:44 PM
No no, not frame as in <frame>, but frame as in internal rendering "frame".

05-22-2006, 06:59 PM
great, for others i found this useful
http://developer.mozilla.org/en/docs/Gecko_Embedding_Basics#Appendix:_Data_Flow_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.