819593 - Keyboard flickers close then open when tapping from one input element to another

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Keyboard, defect, P4)

Description

[Chris Peterson [:cpeterson]]

The keyboard flickers close then open when tapping focus from one input element to another. This problem had previously been addressed by forms.js' blurTimeout (which was removed in bug 811953).

The proposed fix for bug 766066 makes this flickering more apparent because it alters the timing of the keyboard code.

STR:
1. Open Contacts app
2. Add new contact
3. Tap "Last name" field
4. Tap "Company field

RESULT:
The keyboard will flicker close and then reopen. This is unnecessary and looks bad.

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

BB+, P2 - severe usability issue

Comment 2

[Dietrich Ayala (:dietrich)]

We discussed in blocker re-triage today. This is kind of annoying, yes. But it's also just a flicker. The responsiveness is generally pretty good. Would take a patch, but not going to hold the release on this.

Comment 3

[David Scravaglieri [:scravag]]

My bad, no longer depends on 766066

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This isn't fixed by bug 823619.

cpeterson, did you expect 823619 to fix this directly, or is it a prerequisite for some fix you had in mind?

Comment 5

[Chris Peterson [:cpeterson]]

cjones, I don't believe this bug is (directly) related to bug 823619. This bug is caused by forms.js hiding and showing the keyboard in response to a series of focus change events.

ttaubert, forms.js had previously been listening for the "ime-enabled-state-changed" event, but "ime-enabled-state-changed" event was being fired too often. Now that bug 823619 has been fixed, perhaps the "ime-enabled-state-changed" event will work correctly now and you can listen for it in forms.js instead of the focus change events?

Comment 8

[Josh Carpenter [:jcarpenter]]

Has there been any further development on this?

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

I did not continue to work on this.

Comment 11

[Walter Chen[:ypwalter][:wachen]]

Just renominate this since Tim dropped out of this and 2 bugs are marked as duplicated to this bug. Wondering if there would be someone taking over this.

Comment 12

[Walter Chen[:ypwalter][:wachen]]

It has been here since 2012/11 from other bugs.

Comment 13

[Daniel Coloma:dcoloma]

The fact that Tim dropped out the bug should not change its blocking status, we should not hold the release because of this. Marking as leo? just in case someone disagrees for leo version.

Comment 14

[Wayne Chang [:wchang]]

Triage Apr/8 - not blocking leo, tracking b2g18.

Comment 15

[Ben Francis [:benfrancis]]

Estimating as 1 point for now, but may turn out to be more upon further investigation

Comment 16

[Anthony Ricaud (:rik)]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Pointer to Github pull-request

Comment 17

[Anthony Ricaud (:rik)]

Comment on attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Before that patch, we waited 20ms after each focus/blur before showing/hiding the keyboard.
With this patch, we don't wait when we receive a focus event but we wait 100ms after a blur event. That makes the keyboard a bit snappier to appear and less flickers when switching between fields.

Comment 18

[Anthony Ricaud (:rik)]

master: https://github.com/mozilla-b2g/gaia/commit/a91b91bf5ca82b8c78cc1e40bc5650708f29cc48

Comment 19

[Anthony Ricaud (:rik)]

Comment on attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

[Approval Request Comment]
User impact if declined: Interacting with forms will be annoying
Testing completed: 4 days on master without user complaints
Risk to taking this patch (and alternatives if risky): Slows down a bit the keyboard closing time (20ms without the patch, 100ms with).

Comment 20

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I would like UX to chime in. The patch looks safe to me but how much does it bring?

UX can you chime in and re-ask approval? if needed.

Comment 21

[Josh Carpenter [:jcarpenter]]

Definitely want to land this. It resolves a very annoying glitch that we've targeted as UX-Most-Wanted.

Comment 22

[Anthony Ricaud (:rik)]

Comment on attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Re-requesting approval per comment 21.

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Then let's bake it on v1-train.

Comment 24

[James Lal [:lightsofapollo]]

I was not able to uplift this bug to v1-train.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1-train
  git cherry-pick -x  a91b91bf5ca82b8c78cc1e40bc5650708f29cc48
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 25

[James Lal [:lightsofapollo]]

ignore the above uplift magic script exploded =/

v1-train: 57a25d4

Comment 26

[Walter Chen[:ypwalter][:wachen]]

Verified fixed in pvt master unagi build
Gaia:     141ed6da339f477523dcc932217fc0ba7a0ea68d
  B-D     2013-06-15 01:39:53
Gecko:    http://hg.mozilla.org/mozilla-central/rev/36da3cb92193
BuildID   20130616030713
Version   24.0a1