Closed Bug 833983 Opened 9 years ago Closed 9 years ago
Extremely hard to focus contact input fields
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+
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
9 years ago
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.
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.
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
otoro http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=16ab71950a3d1210f7fdacec51015b86d8cd1955 http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=7fdd1dd731ccdcf09e0c51aeefc361adc4bfc11a
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? → -
I'm still able to reproduce this following https://wiki.mozilla.org/B2G/Memory_acceptance_criteria#MW2:_Active_call_stays_active ...
Still hard to reproduce for me in the STR stated. Hope other QAs can help with this.
9 years ago
Duplicate of this bug: 834584
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
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.
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 ...
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)
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.
(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.
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+
Assignee: nobody → jones.chris.g
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Does not make sense to create a regression issue.
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.
You need to log in before you can comment on or make changes to this bug.