Closed Bug 901036 Opened 11 years ago Closed 11 years ago

defect - hard to tap on intended links


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

Windows 8.1


(Not tracked)



(Reporter: jbecerra, Assigned: mbrubeck)



(Whiteboard: feature=defect status=for_sprint c=Content_features u=metro_firefox_user p=3)


(1 file, 1 obsolete file)

Tested on 2013-08-02 using 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.

1. On this type of hardware, Acer Iconia W3, open Firefox Metro
2. Go to
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.
Whiteboard: feature=defect status=for_sprint c=Content_features u=metro_firefox_user p=0
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);

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:

(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.)
Blocks: 780847
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.)
(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.
Assignee: nobody → mbrubeck
OS: Mac OS X → Windows 8 Metro
Hardware: x86 → All
Attached patch radius (obsolete) — Splinter Review
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.
Attachment #785140 - Flags: review?(jmathies)
Comment on attachment 785140 [details] [diff] [review]

Attachment #785140 - Flags: review?(jmathies) → review+
So what are the chances someone comes along and changes these breaking metrofx? Maybe we should define them in metro.js?
Hey Matt, can you provide a point estimate?
Blocks: metrov1it12
No longer blocks: metrov1defect&change
Flags: needinfo?(mbrubeck)
QA Contact: jbecerra
Estimate p=3.  It turns out there *are* some real bugs here that the pref change alone will not fix.
Flags: needinfo?(mbrubeck)
Whiteboard: feature=defect status=for_sprint c=Content_features u=metro_firefox_user p=0 → feature=defect status=for_sprint c=Content_features u=metro_firefox_user p=3
Attached file test case
Test case demonstrating the bug.
Attachment #785140 - Attachment is obsolete: true
Blocks: 837242
Priority: -- → P2
Depends on: 901175
This is fixed by the patch in bug 901175; no Metro-specific work needed here.
Closed: 11 years ago
Resolution: --- → DUPLICATE
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130815030203
Built from

Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and got expected result.
Went through the following "Defect" for iteration #13 without any issues. Used the following build:

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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.