812534 - Touch targets for To, Cc, Bcc, Subject fields don't consistently register touch

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Peter La]

In the E-Mail app, tap the compose icon to compose an email.

Now try tapping through the different fields such as To:, Cc:, Bcc:, and Subject:
Do it a few times.

I find sometimes I cannot get the text field to register my tap, and I have to tap multiple times to get the keyboard up.  It feels really inconsistent.

This could be due to small touch target, slow performance, or some other problem.

Tested on Nov. 15 Unagi nightly build.

Comment 1

[Peter La]

Rewriting with perf/ux-trust bug template.

--

What makes it feel slow/broken?

It's really hard to select the To:, Cc:, Bcc:, and Subject: fields at times.  I may have to tap the field multiple times to select it.

Did it prevent you from doing what you wanted? Why?

Makes the flow of writing E-Mails feel... interrupted/frustrating.

How does this make you feel?

[ ]  :)  I feel happy about it
[ ]  :|  Meh
[ ]  :(  I'm upset
[X] >:O  I'm angry

Device: Unagi, Nov. 22 Nightly.

Details:

This is most likely a touch target size issue, so I've removed the perf tag.

Bonus: can you attach a video of the problem?
Yes

Comment 2

[Dietrich Ayala (:dietrich)]

Seems keyboard related. Feels like the lag is trying to load/unload keyboard when switching between fields.

Comment 3

[Peter La]

Attachment: Compose Fields Difficult to Select - B2G

Comment 4

[Josh Carpenter [:jcarpenter]]

Moving to UX-P1 in hope that fixing this will fix similar problems with keyboard in other situations.

Comment 5

[Josh Carpenter [:jcarpenter]]

Am seeing this in 12/26 build, albeit to a limited degree. More egregious is keyboard's ongoing insistence on closing before I can reposition the cursor, requiring multiple taps and the jarring open/close action of the KB interrupting my flow.

Comment 6

[Josh Carpenter [:jcarpenter]]

I take it back: now I'm seeing this upon switching back into the app and tapping New Email. It is indeed very frustrating to tap away on the fields without any response. 

Andrew, and ideas here?

Nominating blocking:

* Email is core app
* This problem significantly undermines usability of core product flow.
* This problem really pisses the user off, as they tap away without any response on an inert field.

Comment 7

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

Triage:BB-, tracking-b2g18+. function and features still work. just that keyboard closes/opens every time you change text input field. annoying but not blocking ship

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

We've had some platform difficulties with the keyboard recently; part of the issues could be platform and part could be what we're doing...

The compose address fields have special logic in them because of the whole 'bubble' thing we've got going on.  If you look in apps/email/js/compose-cards.js and search for onContainerClick, you'll see we have logic that gets the 'input' element and calls focus on it.  It does this without checking if the input already has focus; it's possible that this causes the specialized on-screen keyboard logic to cause bad things to happen.  While I think we can argue that it's the on-screen keyboard logic's problem if it doesn't allow focus() to be idempotent, it's conceivable we could make things less bad by checking if the input is already focused.  Feel free to play with that.

Comment 9

[smithan]

Attachment: Loading screen when trying to login to email app

Comment 10

[smithan]

Comment on attachment 697411 [details]
Loading screen when trying to login to email app

I could not login to the email app. It showing the loading screen when I click Next button after entering the credentials.

Comment 11

[Jim Porter (:squib)]

(In reply to smithan from comment #10)
> Comment on attachment 697411 [details]
> Loading screen when trying to login to email app
> 
> I could not login to the email app. It showing the loading screen when I
> click Next button after entering the credentials.

This was probably bug 826468.

Comment 12

[Kevin Grandon :kgrandon]

Seems difficult. I'll try.

Comment 13

[Kevin Grandon :kgrandon]

Attachment: Github pull request pointer

Actually wasn't too bad. It seems to be a lot better for me with this patch, which makes the hitbox the full size of each line. (Before it was around 50-60% of the height only).

Comment 14

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

Comment on attachment 699814 [details]
Github pull request pointer

Let's ask r? to Andrew

Comment 15

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 699814 [details]
Github pull request pointer

Looks good!

Comment 16

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

Comment on attachment 699814 [details]
Github pull request pointer

Simple css change. a=me.

Comment 17

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

https://github.com/mozilla-b2g/gaia/commit/129354a8cf4b441a7e593aac744d8896fbf3741c

Comment 18

[Mila Davydova]

This issue does not reproduce on Unagi build ID:20130112070202

Comment 19

[Angela Hubenya]

Issue is verified as fixed. Removing qawanted