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.
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
Seems keyboard related. Feels like the lag is trying to load/unload keyboard when switching between fields.
Depends on: 814758
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
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
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: --- → ?
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.
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.
Whiteboard: interaction, UX-P1 → interaction, UX-P1, BerlinWW
(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.
Seems difficult. I'll try.
Assignee: nobody → kgrandon
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!
Comment on attachment 699814 [details] Github pull request pointer Simple css change. a=me.
Attachment #699814 - Flags: approval-gaia-master?(21) → approval-gaia-master+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
This issue does not reproduce on Unagi build ID:20130112070202
Status: RESOLVED → VERIFIED
Issue is verified as fixed. Removing qawanted
You need to log in before you can comment on or make changes to this bug.