I was observing this on http://play.fxhome.mozillalabs.com:6543/ on a Galaxy Nexus. The page layout is such that on the GN, the "Mozilla labs" image gets positioned so that it overlaps the "Sign up to try Pancake" link. Tapping on the overlap area results in haptic feedback but no link-navigation. I added some logging to browser.js and see that touchstart event is fired on the image element, but since ElementTouchHelper.isElementClickable returns false for it, it finds a new element (the anchor element underneath it) and uses that as the highlight element. When the Gesture:SingleTap code is run, it calls _sendMouseEvent with just the x/y coordinates, and that sends the mouse event to the image element rather than the anchor. The isClickable boolean is still true though, because _highlightElement is the anchor, and so there is haptic feedback. I'm not sure what the correct fix is here, but I think it involves modifying the elementFromPoint code to ensure that it doesn't return an element that is under something else. :wesj, any thoughts?

This patch does two things: 1) refactors the code that moves the mouse-event point so that it doesn't run 3 times for each tap 2) Updates the isClickable variable based on where the point was moved to, so that we don't provide haptic feedback if we send the click to a non-clickable element. This means that for bugs like this one (and bug 773427), the item still won't be clickable, but now we won't provide haptic feedback that confuses the user. It's perfectly legitimate for some things to not be clickable, such as in this bug where the image is on top of the link.

Clearly I didn't test that patch at all. Updated with correct arguments to anyElementFromPoint so it doesn't break all clicking.