901036 - defect - hard to tap on intended links

Status: RESOLVED DUPLICATE of bug 901175

(Firefox for Metro Graveyard :: Input, defect, P2)

Description

[juan becerra [:juanb]]

Tested on 2013-08-02 using https://tbpl.mozilla.org/?tree=Try&showall=0&rev=12e7404f9314 I am using an Iconia W3, and I am having a hard time clicking (tap) on the right link. If there is a link above the one I intend on tapping, then that link gets clicked, so I have to be very careful. I haven't noticed this problem on other machines.

Steps:
1. On this type of hardware, Acer Iconia W3, open Firefox Metro
2. Go to https://tbpl.mozilla.org/?tree=Try&showall=0&rev=12e7404f9314
3. Try to tap on the middle changeset link in the group of three at the bottom.

Expected: I am able to click on that middle link that takes me to that changeset.

Actual: It takes me a few tries before I can tap that link. It usually opens the one above.

Comment 1

[Matt Brubeck (:mbrubeck)]

Currently we have:

  pref("ui.mouse.radius.leftmm", 8);
  pref("ui.mouse.radius.topmm", 12);
  pref("ui.mouse.radius.rightmm", 8);
  pref("ui.mouse.radius.bottommm", 4);

http://hg.mozilla.org/mozilla-central/file/d3a0ac52d5d4/modules/libpref/src/init/all.js#l2105

This means that we intentionally look more up than down when looking for a nearby link.  I think this was set back in 2009 or 2010 based on some assumptions about touch screens that may no longer be true.  In particular, operating systems today might be better at mapping touch input to the point the user actually wanted to touch, without being biased in a particular direction.

I'd suggest trying more a more symmetric and smaller radius, maybe more similar to B2G:
https://hg.mozilla.org/mozilla-central/rev/c7f04c4993a2

(It's also possible that this is just a bug in the ui.mouse.radius.enabled code; we should verify that it's applying the prefs as intended.  I think the tests for this code are pretty thorough so it's *probably* working correctly.)

Comment 2

[Asa Dotzler [:asa]]

I'm concerned about going much smaller but it's also possible all of my 'misses' are a result of the short side of that radius, perhaps because of the angle of my screen or something? 

Can we make it symetrical first and then discuss shrinking it? 

(Btw, I miss the close x in tab thumbnails in the tab strip more than 50% of the time, as just an example of my concern about getting even smaller with the targeting.)

Comment 3

[Matt Brubeck (:mbrubeck)]

(In reply to Asa Dotzler [:asa] from comment #2)
> Can we make it symetrical first and then discuss shrinking it? 

Sounds good.  Patch on the way.

> (Btw, I miss the close x in tab thumbnails in the tab strip more than 50% of
> the time, as just an example of my concern about getting even smaller with
> the targeting.)

We effectively disabled target-fluffing for a lot of our browser chrome (including the tab strip) to work around bugs.  We just landed a patch in bug 899987 that should improve those cases specifically.

Comment 4

[Matt Brubeck (:mbrubeck)]

Attachment: radius

Note: Metro Firefox is currently the only product that uses these defaults from all.js.  Firefox OS overrides them in b2g.js, and other products do not use this code at all.

Comment 5

[Jim Mathies [:jimm]]

Comment on attachment 785140 [details] [diff] [review]
radius

wfm!

Comment 6

[Jim Mathies [:jimm]]

So what are the chances someone comes along and changes these breaking metrofx? Maybe we should define them in metro.js?

Comment 7

[Marco Mucci [:MarcoM]]

Hey Matt, can you provide a point estimate?

Comment 8

[Matt Brubeck (:mbrubeck)]

Estimate p=3.  It turns out there *are* some real bugs here that the pref change alone will not fix.

Comment 9

[Matt Brubeck (:mbrubeck)]

Attachment: test case

Test case demonstrating the bug.

Comment 10

[Matt Brubeck (:mbrubeck)]

This is fixed by the patch in bug 901175; no Metro-specific work needed here.

Comment 11

[Samvedana (:Samvedana)]

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130815030203
Built from http://hg.mozilla.org/mozilla-central/rev/a8daa428ccbc

WFM
Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and got expected result.

Comment 12

[Kamil Jozwiak [:kjozwiak]]

Went through the following "Defect" for iteration #13 without any issues. Used the following build:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-09-01-03-02-18-mozilla-central/

Tested this with the Lenovo X1 Carbon as I don't have the particular device mentioned in comment #0.

- Went through the original issue from comment #0 without any issues
- Tapped on all the links without any issues (opened the correct links)
- Ensured that opening the links using "Open in new tab" through the context menu worked without any issues
- Went through all of the above test cases using filled view without any issues