Created attachment 568801 [details] WIP Patch In old Fennec, we would look for elements near to where the user "clicked" for clickable elements. It'd be nice to do this in our new world. Previously we had a shield that would absorb clicks, and we then redirected those clicks to the child process. In our new world the clicks happen directly on the browser. I'm playing with checking if the user actually clicked on a clickable element. If so we just let the normal world take its course. If the user only clicked close to a clickable element we fire a second "new" click on the actual clickable guy. I'm a bit worried about that firing multiple clicks and need to play with it some. Happy to hear if there are any good/better ideas about how to do this. In future plans, we were hoping to zoom into the area where there were multiple clickable elements.
*** Bug 696325 has been marked as a duplicate of this bug. ***
Created attachment 570356 [details] [diff] [review] Patch v1 This is a lot of code, all of it copied (almost) exactly from content.js. There were numerous references to Util.js in there that I removed. I also removed a mousemove we usually fire there because it scares me to fire mousemoves with our new UI. A bit hard to test too. I think my fingers have adjusted to tapping on stuff correctly. But some logging along with some light browsing shows this getting hit and finding the right things.
Comment on attachment 570356 [details] [diff] [review] Patch v1 We should try to get some of our browser-chrome tests running on birch so we can test this too.
http://hg.mozilla.org/projects/birch/rev/8447eaf8f0f8
I came across this, this May, and it seemed to be nice. Probably the 'zoom' thing can have this behavior. http://vis.berkeley.edu/papers/fingerglass/
or
