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

VERIFIED FIXED

Status

Firefox OS
Gaia::E-Mail
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: Peter La, Assigned: kgrandon)

Tracking

unspecified
All
Other

Firefox Tracking Flags

(blocking-basecamp:-, b2g18+ fixed)

Details

(Whiteboard: interaction, UX-P1, BerlinWW)

Attachments

(3 attachments)

(Reporter)

Description

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

Updated

6 years ago
QA Contact: dclarke

Updated

6 years ago
Keywords: polish
Priority: -- → P2
(Reporter)

Updated

6 years ago
Keywords: perf, polish → ux-trust
Whiteboard: ux-trust
(Reporter)

Comment 1

6 years ago
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
Priority: P2 → P1
Seems keyboard related. Feels like the lag is trying to load/unload keyboard when switching between fields.
Depends on: 814758
(Reporter)

Updated

6 years ago
Summary: [Gaia::E-Mail][perf] Touch targets for To, Cc, Bcc, Subject fields don't consistently register touch → [Gaia::E-Mail] Touch targets for To, Cc, Bcc, Subject fields don't consistently register touch
(Reporter)

Comment 3

6 years ago
Created attachment 685730 [details]
Compose Fields Difficult to Select - B2G
Keywords: ux-trust
Priority: P1 → --
Summary: [Gaia::E-Mail] Touch targets for To, Cc, Bcc, Subject fields don't consistently register touch → Touch targets for To, Cc, Bcc, Subject fields don't consistently register touch
Whiteboard: ux-trust → interaction, UX-P2
Moving to UX-P1 in hope that fixing this will fix similar problems with keyboard in other situations.
Whiteboard: interaction, UX-P2 → interaction, UX-P1
Keywords: qawanted
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.
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.
blocking-basecamp: --- → ?
Flags: needinfo?(bugmail)
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
blocking-basecamp: ? → -
tracking-b2g18: --- → +
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.
Flags: needinfo?(bugmail)
Assignee: nobody → smithan

Comment 9

5 years ago
Created attachment 697411 [details]
Loading screen when trying to login to email app

Comment 10

5 years ago
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.
Assignee: smithan → nobody
Whiteboard: interaction, UX-P1 → interaction, UX-P1, BerlinWW

Comment 11

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

Comment 12

5 years ago
Seems difficult. I'll try.
Assignee: nobody → kgrandon
(Assignee)

Comment 13

5 years ago
Created attachment 699814 [details]
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).
Attachment #699814 - Flags: review?(21)
Comment on attachment 699814 [details]
Github pull request pointer

Let's ask r? to Andrew
Attachment #699814 - Flags: review?(21) → review?(bugmail)
Comment on attachment 699814 [details]
Github pull request pointer

Looks good!
Attachment #699814 - Flags: review?(bugmail)
Attachment #699814 - Flags: review+
Attachment #699814 - Flags: approval-gaia-master?(21)
Comment on attachment 699814 [details]
Github pull request pointer

Simple css change. a=me.
Attachment #699814 - Flags: approval-gaia-master?(21) → approval-gaia-master+

Comment 18

5 years ago
This issue does not reproduce on Unagi build ID:20130112070202
Status: RESOLVED → VERIFIED
status-b2g18: --- → fixed

Comment 19

5 years ago
Issue is verified as fixed. Removing qawanted
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.