defect - hard to tap on intended links

RESOLVED DUPLICATE of bug 901175

Status

defect
P2
normal
RESOLVED DUPLICATE of bug 901175
6 years ago
5 years ago

People

(Reporter: jbecerra, Assigned: mbrubeck)

Tracking

Trunk
All
Windows 8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

6 years ago
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.
Whiteboard: feature=defect status=for_sprint c=Content_features u=metro_firefox_user p=0
Assignee

Comment 1

6 years ago
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.)
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.)
Assignee

Comment 3

6 years ago
(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
Status: NEW → ASSIGNED
OS: Mac OS X → Windows 8 Metro
Hardware: x86 → All
Assignee

Comment 4

6 years ago
Posted 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]
radius

wfm!
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
Assignee

Comment 8

6 years ago
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
Assignee

Comment 9

6 years ago
Posted file test case
Test case demonstrating the bug.
Attachment #785140 - Attachment is obsolete: true
Assignee

Updated

6 years ago
Blocks: 837242
Priority: -- → P2
Depends on: 901175
Assignee

Comment 10

6 years ago
This is fixed by the patch in bug 901175; no Metro-specific work needed here.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 901175
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.
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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.