Closed Bug 971335 Opened 11 years ago Closed 11 years ago

[B2G][Email]Long outgoing Email Address truncated at top of new popup screen for manual setup of IMAP+SMTP account on device

Categories

(Core :: Panning and Zooming, defect)

28 Branch
ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
tracking-b2g backlog
Tracking Status
b2g-v1.2 --- unaffected
b2g-v1.3 --- affected

People

(Reporter: mclemmons, Assigned: kats)

References

()

Details

(Keywords: regression, Whiteboard: burirun1.3-3)

Attachments

(2 files)

Attached image Truncation screenshot
User attempt to create a new email with an outgoing email address in excess of 20 characters is truncated on popup screen after selected within device bubble for email account of IMAP+SMTP on device Repro Steps: 1) Updated Buri to BuildID: 20140210004002 2) Tap Email App and select pencil in box to create new email 3) In “To:” field, type a long email address (ex: qwertyuiopasdfghjklzxcvbnm@yahoo.com) 4) Tap Space key 5) Tap on address Actual: Address is truncated as it slides slowly from right to left and displays as qwertyuiopasdfghjklzxcvbnm@yahoo.co with the letter o not shown in full Expected: Full address qwertyuiopasdfghjklzxcvbnm@yahoo.com displayed Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140210004002 Gaia: 5c8416fb1ea4a27f172ee6386ab3c19135448506 Gecko: 9c9382f433c0 Version: 28.0 Firmware Version: V1.2-device.cfg Notes: 1. Repro frequency: (5/5, 100%) 2. Link to failed test case: https://moztrap.mozilla.org/manage/case/8588/ 3. See attached: (video clip = http://youtu.be/5Aui_wpRqFc, screenshot, logcat) 4. The type of device in use - Buri 5. The "Build Identifier" of the build you are using - BuildID: 20140210004002 6. Confirm the net connection is working - confirmed 7. The e-mail domain you used/are using to create the account - aol.com 8. If this is not a problem creating the account, the account type the e-mail client thinks it is using – "IMAP+SMTP". 9. A log of what was happening around the time the problem happened - Attached
This issue does not reproduce on Buri 1.2 Following the STR in Comment 0 the full email address displays after selecting the bubble Environmental Variables: Device: Buri 1.2 MOZ BuildID: 20140210004002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: 2673f348598c Version: 26.0 Firmware Version: v1.2-device.cfg
The behavior here looks right actually - the marquee is active here showing the user the email address in full. Why is this bug?
Flags: needinfo?(mclemmons)
Please observe the attached screenshot and video. The domain is not presented in full (i.e. yahoo.co instead of yahoo.com)
Flags: needinfo?(mclemmons)
Okay - I see the bug now. A longer email will lose it's last X characters if the email address exceeds the width of the prompt. The more characters you add, the worse it gets. Seems like this means that you only get a partial understanding of the longer email address after you add it, as there's no way to find out the full longer email address after you add it due to this bug. UX - Can you weigh in on the severity of the bug here? Do you guys think we need this in 1.3?
Flags: needinfo?(firefoxos-ux-bugzilla)
Keywords: regression
Flagging Juwei. I'm concerned the user may not be able to see the email to correct it (if it's wrong); could inadvertently send to the wrong address, and so on.
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(jhuang)
(In reply to Stephany Wilkes from comment #6) > Flagging Juwei. I'm concerned the user may not be able to see the email to > correct it (if it's wrong); could inadvertently send to the wrong address, > and so on. Good point. I think that gives me enough to go off of that this is bad UX actually.
blocking-b2g: --- → 1.3?
It's really bad. it should show the whole email address. Hi Andrew, could you please help to check this? thanks!
Flags: needinfo?(jhuang) → needinfo?(bugmail)
(:jrburke is the owner of the front-end/UI and is less backlogged/more diligent than me :)
Flags: needinfo?(bugmail) → needinfo?(jrburke)
Dylan Please review
blocking-b2g: 1.3? → backlog
Flags: needinfo?(doliver)
Can we back out whatever caused this?
This appears to be an APZC issue. If do the following, the problem disappears: * Close the email app completely * Long press power button to get restart menu * tap "Disable APZ for Apps" * restart the email app It then works. So this should go in the APZC issue bucket. I tried a few workarounds in the app code, but nothing seemed to work. However disabling APZC did work.
Flags: needinfo?(jrburke)
Flags: needinfo?(doliver)
Blocks: gaia-apzc-2
Component: Gaia::E-Mail → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → 28 Branch
At a first glance this might be some bad interaction between OMTA and APZC/displayport. I'll investigate.
Assignee: nobody → bugmail.mozilla
I updated to the latest 1.3 code and I can no longer reproduce this. Maybe it got fixed? qawanted to retest.
Keywords: qawanted
Reporter - Can you retest?
Flags: needinfo?(mclemmons)
In response to Comment 15 Jason Smith [:jsmith] 2014-02-20 10:46:44 PST Reporter - Can you retest? I am unable to reproduce the reported error in Comment 0 using the same STR with the below Environmental Variables: Environmental Variables: Device: buri 1.3 MOZ BuildID: 20140220004003 Gaia: a43904d9646109b48836d62f7aa51e499fbf4b2e Gecko: 32fd5d798477 Version: 28.0 Base Image: v1.2-device.cfg
Flags: needinfo?(mclemmons)
Sounds like WFM. Feel free to reopen if I misunderstood.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Keywords: qawanted
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: