Yeah, so what?

The problem comes when we want to mask a part of the screen, but also want the elements behind that mask to continue responding to user interaction. This behavior is counter to most native behavior. What we are left with, is having to forward mouse events through the masking layer to the layer below, an option that simply does not exist in the standard JavaScript/DOM API.

Why do this?

A plugin that I recently wrote – DataDrop - used a textarea overlaying a grid to act as the receiver of dragged data from spreadsheet type programs. One of the limitations that I was not so happy about was the fact that this overlay could only exist in the ‘empty’ area of the grid, not over rows of data, headers, toolbars, etc. otherwise it would cause all of those elements below to become unresponsive to user input. If our textarea that receives the data were positioned over the entire grid area, our GridPanel could not be controlled using the mouse anymore.

How to fix this?

This is where my friend Nige White (Animal) came in to help, it turns out that he had an idea about how to forward these mouse events using a couple of not well understood methods in the JavaScript/DOM API used for creating mouse events. Here are the steps taken:

1. The textarea (my masking element) that is positioned over the grid receives mouseover, mousemove, mousedown , mouseup and other events.
2. The top masking layer is hidden for a moment, so we can figure out what element is below the mask at the event location.
3. The event is re-fired – this is where the W3 DOM Event model and the simpler Microsoft equivalent come into play.
4. Start the process again – ready for the next event.

What’s element to fire upon?

Knowing the cursor position and event that occurred, the only obstacle now is determining what DOM element to fire the simulated event through. It turns out that finding which element is the topmost element at a certain document coordinate position is quite simple in modern browsers. The document.elementFromPoint method is supported in IE, Mozilla, Webkit and Opera.

So it is possible to capture the document coordinates of a mouse event fired on the masking element, momentarily hide that masking element, and then ask the document what is under that coordinate position before showing the mask again.

A new event can be then fired on the found element. Obviously there are some complexities such as firing mouseover and mouseout events when the found element is different from the last time, but that is the gist of the technique. To see it in action, check out the screencast or play with the live Grid DataDrop example or simple DOM element example yourself.

I have posted an override of Ext.Element that Nigel created on my Google Code site for all to enjoy, it is now a requirement for the ExtJS DataDrop plugin. A big thanks goes out to Nige (Animal) for digging into the nuts and bolts of JavaScript to find a solution to my problem.

The Next Step

Having the data that is dropped into the grid automatically insert into the grids rows at the correct position is my next task for the ever-improving DataDrop plugin. Should be fun :/

UPDATE (12-1-09): Seems that Mozilla has also noticed this issue.