Comments on: Smart Tapping in Mobile Firefox

By: Gordon P. Hemsley

Gordon P. Hemsley — Mon, 07 Jun 2010 05:41:01 +0000

This all sounds reasonable, but there is one unmentioned caveat that could quickly become a major annoyance: If there are a number of links close together, and you accidentally tap on the wrong one the first time you try, future taps in that same area will keep giving you the same wrong link (since visited links are favored).

Just something to keep in mind.

By: Tomas

Tomas — Fri, 14 May 2010 16:39:53 +0000

Dave: Some OS’s offset the tap, some do not, so it makes sense to make it configurable as the post suggests. Also, if Firefox wants to do in-browser rotation (i.e. rotation of the content is performed by the application itself instead of the OS) at some point, it’s important that Firefox is able to correct the tap offset in the right direction as well.

By: Dave Hulbert

Dave Hulbert — Fri, 14 May 2010 07:40:39 +0000

This sounds great, but shouldn’t the offsetting the tap area up a few pixels be done by the OS instead of the program?

By: Matt Brubeck

Matt Brubeck — Thu, 13 May 2010 20:59:36 +0000

jmdesp: Fennec does give visual feedback when you first press the screen, and you can cancel your touch by moving your finger away before lifting it.

You can’t shift focus to a different element by sliding with your finger still pressed, because Fennec scrolls the page when you do that.

By: Mark Finkle

Mark Finkle — Thu, 13 May 2010 14:50:26 +0000

@voracity – elementFromPoint does not do anything with visited links, it merely returns the element at the point. The new API, nodesFromRect, doesn’t do anything directly with visited links either. The Firefox front-end code applies the weighting separately. Nothing is leaked to content, that I can think of anyway.

By: voracity

voracity — Thu, 13 May 2010 13:08:27 +0000

“The platform already exposes an elementFromPoint API to chrome and web content.”

Wouldn’t this be a privacy issue, similar to the :visited one? (Albeit, a lot harder to take advantage of.)

By: Kadir

Kadir — Thu, 13 May 2010 12:52:23 +0000

Wow, awesome improvement, can’t wait to try this out on my iPhone. Oh, wait, right :/

By: jmdesp

jmdesp — Thu, 13 May 2010 10:19:52 +0000

I think what you need truly is “hit and slide”.
The thing that’s really hard to do is to, with a high precision, watch the screen, see an element and be able to hit exactly on that element on first try. But after you have hit the screen, if something shows you where you really are, you will be able to correct your position with a much higher resolution.

So what the interface should do is after you hit the screen, give you a very visible return on what you have hit, and *not* act until you *raise* your finger (or stay for some delay on the element), and letting you *slide* on the surface to select something else if you realized you hit the wrong element, still giving you as you slide a visible return on what the current hit is.

By: David Baron

David Baron — Thu, 13 May 2010 06:48:54 +0000

Rather than weighting the elements by z-order, might it be better to take a sample of points in the region around the touch, find the topmost element at each point, and then weight the elements by distance-from-touch and frequency within that sample? It doesn’t seem like z-order should matter for elements that don’t overlap (and might cause bias in the results, requiring touching higher on the display to avoid being too close to the next line); and sampling the topmost element at different points ought to account for z-order when it does matter.