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

VERIFIED FIXED

Status

Firefox OS
Gaia::Keyboard
P4
normal
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: cpeterson, Unassigned)

Tracking

({perf})

unspecified
All
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:-, b2g18 fixed)

Details

(Whiteboard: TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 s=sprint-1 swat-team)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Blocks: 811953
(Reporter)

Updated

5 years ago
Blocks: 766066
No longer depends on: 766066
BB+, P2 - severe usability issue
Assignee: nobody → ttaubert
blocking-basecamp: ? → +
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.
blocking-basecamp: + → -
Priority: P2 → P4
blocking-basecamp: - → ?
Whiteboard: [target:12/21]
My bad, no longer depends on 766066
blocking-basecamp: ? → -
Whiteboard: [target:12/21]
No longer blocks: 766066
Depends on: 823619
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?
Flags: needinfo?(cpeterson)
(Reporter)

Comment 5

5 years ago
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?
Flags: needinfo?(cpeterson)
Duplicate of this bug: 829484

Updated

5 years ago
Whiteboard: UX-P2, interaction

Updated

5 years ago
Whiteboard: UX-P2, interaction → UX-P2, interaction, TEF_REQ

Updated

5 years ago
Duplicate of this bug: 832293

Updated

5 years ago
Keywords: perf
Whiteboard: UX-P2, interaction, TEF_REQ → UX-P1, interaction, TEF_REQ, PRODUCT-ANNOYING
Whiteboard: UX-P1, interaction, TEF_REQ, PRODUCT-ANNOYING → u=user c=keyboard s=ux-most-wanted, TEF_REQ, PRODUCT-ANNOYING
Has there been any further development on this?
I did not continue to work on this.
Assignee: ttaubert → nobody

Updated

5 years ago
Whiteboard: u=user c=keyboard s=ux-most-wanted, TEF_REQ, PRODUCT-ANNOYING → TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard s=ux-most-wanted
Duplicate of this bug: 811656
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.
blocking-b2g: --- → tef?
It has been here since 2012/11 from other bugs.
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.
blocking-b2g: tef? → leo?
Triage Apr/8 - not blocking leo, tracking b2g18.
blocking-b2g: leo? → -
tracking-b2g18: --- → +
Whiteboard: TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard s=ux-most-wanted → TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard s=ux-most-wanted swat-team
Estimating as 1 point for now, but may turn out to be more upon further investigation
Whiteboard: TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard s=ux-most-wanted swat-team → TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 s=ux-most-wanted swat-team
Whiteboard: TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 s=ux-most-wanted swat-team → TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 swat-team
Whiteboard: TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 swat-team → TEF_REQ, PRODUCT-ANNOYING, u=user c=keyboard p=1 s=sprint-1 swat-team
Created attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Pointer to Github pull-request
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.
Attachment #739085 - Flags: review?(21)
Attachment #739085 - Flags: review?(21) → review+
master: https://github.com/mozilla-b2g/gaia/commit/a91b91bf5ca82b8c78cc1e40bc5650708f29cc48
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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).
Attachment #739085 - Flags: approval-gaia-v1?(21)
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.
Flags: needinfo?(jcarpenter)
Attachment #739085 - Flags: approval-gaia-v1?(21)
Definitely want to land this. It resolves a very annoying glitch that we've targeted as UX-Most-Wanted.
blocking-b2g: - → ---
tracking-b2g18: + → ---
Flags: needinfo?(jcarpenter)
Comment on attachment 739085 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9287

Re-requesting approval per comment 21.
Attachment #739085 - Flags: approval-gaia-v1?(21)
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.
Attachment #739085 - Flags: approval-gaia-v1?(21) → approval-gaia-v1+
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
ignore the above uplift magic script exploded =/

v1-train: 57a25d4
status-b2g18: --- → fixed
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.