Closed Bug 833983 Opened 10 years ago Closed 10 years ago

Extremely hard to focus contact input fields

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:tef+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 verified, b2g18-v1.0.0 fixed, b2g18-v1.0.1 verified)

Status:
VERIFIED FIXED
Milestone:
B2G C4 (2jan on)
Project Flags:
blocking-b2g tef+
Tracking Flags:
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- verified
b2g18-v1.0.0 --- fixed
b2g18-v1.0.1 --- verified

People

(Reporter: cjones, Assigned: cjones)

References

Details

(Keywords: regression, Whiteboard: DUPEME, [MZ])

Attachments

(1 file)

Don't preventDefault() drags that aren't quite pans
821 bytes, patch
schien
: review+
Details | Diff | Splinter Review 
STR
 (1) Open contacts app
 (2) Tap "+" to add new contact
 (3) Try to focus any of the input fields

It takes me 3 or 4 tries.

Something we obviously want to work ...
Assignee: nobody → rlu
blocking-b2g: tef? → tef+
Keywords: regression
More STR:

1. add a new contact
2. switch focus between company and phone fields 10 times, and stop

sit back and watch keyboard open and close repeatedly for 20 seconds
Hi all,

I could not reproduce what Chris mentioned in Comment 0 (hard to focus) with PVT build: Build ID - 20130123070202.

For what Dietrich mentioned in Comment 1, I think it is more or less the same issue as Bug 819593 - Keyboard flickers close then open when tapping from one input element to another.

Mark qawanted to get some helps to reproduce it.
Keywords: qawanted
Hi, Chris Jones, 
Can you provide your version of B2G code and kernel version please?
Touch related issues are highly reproducible when B2G gaia code doesn't get renewed.
Also, kernel might matter a little bit.

I can't reproduce it in pvt b2g18 2013-01-23 build.

Hi, Dietrich Ayala,
I can reproduct ur STR. 
However, it is obviously that your STR is not the same bug as the original bug. If possible, please refile a bug. That would help us to separate issues/bugs.
Flags: needinfo?(jones.chris.g)
Flags: needinfo?(dietrich)
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Hi all,

I still could not reproduce this issue with the same rev. info as Comment 4 on Otoro.

Hi Chris,

Might be a stupid question, is it possible that you triggered scrolling (horizontally) or something instead of click event?

BTW, the keyboard app code is there unchanged for a while.
So, I might not be the right person to look into this.
Assignee: rlu → nobody
If I triggered any scrolling logic, the UI didn't change in response.
Going to renom - we don't have enough info to go forward.
blocking-b2g: tef+ → tef?
Not a blocker until we can reliably reproduce.
blocking-b2g: tef? → -
Still hard to reproduce for me in the STR stated.
Hope other QAs can help with this.
Hmm...so the dupe implies someone can reproduce this.

Walter - Does the dupe give any insight into reproducing this bug?
I retried several times.
Also, I tried with Chris's STR.
However, I don't know how to reproduce it.

Jason, can you try to reproduce it?
Additional information...
The bug also occurred in new inari phone.
The fact that we only see this intermittently makes me think bug 829234 might be the problem.  However, bug 829234 has been a problem "forever" (AFAIK), and the focusability of inputs seems to have regressed in the last few weeks/month.
Depends on: 829234
Whiteboard: DUPEME → DUPEME, [MZ]
Hi all,

It seems this issue depends on if the page is scrollable.

1. Can reproduce, if the page is scrollable.
   - Create a new contact in Contact App.
   - Keyboard test page in UI Test app.

2. Cannot reproduce when the page that contains the input is not scrollable
   - Add a new event Calendar app
   - Start a new message in SMS app


I added a simple test case to UI test app to double confirm,
You may get the test case with:
git pull https://github.com/RudyLu/gaia focus/Bug833983-input-hardTofocus

--
BTW, this issue can be reproduced with HEAD rev. of Gecko-18 branch on Otoro,
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=e2abfafb7d88df1ed6bf8bcfedb4b0a5dafb7313
Gaia: the latest, should not be relevant to this issue
Interesting, thanks for investigating!

This makes me think bug 829234 is more likely, since in BrowserElementScrolling we only check if the user is trying to pan if there are scrollable elements on the page.
Bug 828367 regressed this.
Depends on: 828367
No longer depends on: 829234
Flags: needinfo?(dietrich)
SC, do you remember why the preventDefault() is needed here?

http://hg.mozilla.org/mozilla-central/rev/cae4668deecd#l1.15

That's what's cancelling the tap.  I don't believe it's necessary, but checking ...
Flags: needinfo?(schien)
Let's move things along a bit more with a review request.  This doesn't regress the STR in bug 828367.
Attachment #711085 - Flags: review?(schien)
Flags: needinfo?(schien)
Can we get this tef+ 'd?   this patch will fix a bunch of touch issues that we're testing against the Inari for MWC demos.
blocking-b2g: - → tef?
removing qawanted, as this was clearly a visible issue on the Inari phones.
Keywords: qawanted
(In reply to Chris Jones [:cjones] [:warhammer] from comment #19)
> SC, do you remember why the preventDefault() is needed here?
> 
> http://hg.mozilla.org/mozilla-central/rev/cae4668deecd#l1.15
> 
> That's what's cancelling the tap.  I don't believe it's necessary, but
> checking ...
PreventDefault() in here is to prevent APZC entering TOUCHING state before BES hand over the scrolling action back to APZC. 
http://dxr.mozilla.org/mozilla-central/gfx/layers/ipc/AsyncPanZoomController.cpp.html#l1436
If we remove this preventDefault(), we'll not be able to scroll slowly on a subframe.

I'll put my full attention on this bug today and find out why this preventDefault() don't cause tap problem on m-c.
I thought APZC only honored preventDefault() on touchstart events.  (That was the original intention, anyway.)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #31)
> I thought APZC only honored preventDefault() on touchstart events.  (That
> was the original intention, anyway.)
In the subframe scrolling detection scenario, touch events are queued from touchmove and it'll depends on the preventDefault information on touchmove events.
I'm not following that :).  But if you're investigating today, happy to see what you find.
blocking-b2g: tef? → tef+
Comment on attachment 711085 [details] [diff] [review]
Don't preventDefault() drags that aren't quite pans

Review of attachment 711085 [details] [diff] [review]:
-----------------------------------------------------------------

@cjones, you're right. This preventDefault() doesn't help on the scenario I described in comment 30 but causes trouble. Let's remove this buggy code.
Attachment #711085 - Flags: review?(schien) → review+
https://hg.mozilla.org/mozilla-central/rev/4a2f6b878f6e
Assignee: nobody → jones.chris.g
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Does not make sense to create a regression issue.
Flags: in-moztrap-
Unagi Build: 20130322070202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/5aacf880400b
Gaia:  5a31a56b96a8fc559232d35dabf20411b9c2ca1d
Kernel: Dec 5th


In the Unagi build above, I've verified that the fields described with the issue gain and lose focus just fine in Contacts. I'm able to switch fast or tap anywhere in the field for it to gain focus.

Marking as Verified Fixed.
Status: RESOLVED → VERIFIED
status-b2g18-v1.0.1: --- → verified
You need to log in before you can comment on or make changes to this bug.