Last Comment Bug 696512 - Redirect clicks to clickable elements nearby (smart link tapping)
: Redirect clicks to clickable elements nearby (smart link tapping)
Product: Firefox for Android
Classification: Client Software
Component: General (show other bugs)
: unspecified
: All All
P2 normal (vote)
: ---
Assigned To: Wesley Johnston (:wesj)
: Sebastian Kaspari (:sebastian)
: 696325 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-10-21 16:03 PDT by Wesley Johnston (:wesj)
Modified: 2012-01-09 15:31 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

WIP Patch (9.98 KB, text/plain)
2011-10-21 16:03 PDT, Wesley Johnston (:wesj)
no flags Details
Patch v1 (8.68 KB, patch)
2011-10-28 14:02 PDT, Wesley Johnston (:wesj)
mbrubeck: review+
Details | Diff | Splinter Review

Description User image Wesley Johnston (:wesj) 2011-10-21 16:03:13 PDT
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.
Comment 1 User image Mark Finkle (:mfinkle) (use needinfo?) 2011-10-22 14:39:18 PDT
*** Bug 696325 has been marked as a duplicate of this bug. ***
Comment 2 User image Wesley Johnston (:wesj) 2011-10-28 14:02:57 PDT
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 3 User image Matt Brubeck (:mbrubeck) 2011-10-28 14:33:08 PDT
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.
Comment 4 User image Wesley Johnston (:wesj) 2011-10-28 17:12:31 PDT
Comment 5 User image Sriram Ramasubramanian [:sriram] 2011-10-28 21:40:26 PDT
I came across this, this May, and it seemed to be nice. Probably the 'zoom' thing can have this behavior.

Note You need to log in before you can comment on or make changes to this bug.