Closed Bug 1135931 Opened 6 years ago Closed 6 years ago

[RTL][Email] There is not a space between emails that have long sender names and dates


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

Gonk (Firefox OS)


(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master verified)

2.2 S8 (20mar)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- verified
b2g-master --- verified


(Reporter: KTucker, Assigned: jrburke)




(Whiteboard: [3.0-Daily-Testing])


(3 files)

Emails that have longer sender names are running into the dates. There is not a space between the two. 

The user is signed into a Yahoo email account.

Repro Steps:
1) Update a Flame to 20150223010224
2) Change the language to Arabic.
3) From a desktop, create a yahoo email account that has a really long first name and last name.
3) From that account created on the desktop, send an email to the user's yahoo account that is currently signed in on the dut.
4) Check the user's inbox on the dut for the email sent in step 3 to make sure that it has been received.
5) Manually change the date on the dut to a date that is a year from now.
6) Force close the email app.
7) Reopen the email app.
8) Go to the inbox and look at the sender name and the date for that email sent in step 3.

The sender name and date will be spaced correctly until the user force closes the email app. After reopening the app, the user will notice that there is not a space between the long sender name and date. 

There should always be a space between long sender names and dates.

Environmental Variables:
Device: Flame 3.0 (Full Flash)(KK)(319mb)
Build ID: 20150223010224
Gaia: a6881205deae450757a8d1e1ed65e5e5be0ec633
Gecko: 86d2bb8bb1c9
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 5/5, 100%
See attached: video
QA Whiteboard: [rtl-impact]
This issue also occurs on the Flame 2.2

Long sender names and dates do not have spaces between them.

Environmental Variables:
Device: Flame 2.2(Full Flash)(KK)(319mb)
BuildID: 20150223002503
Gaia: 389542b71c89253c0d176d3b0bfb54e275c19bf1
Gecko: 9fd3441c8983
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [rtl-impact] → [rtl-impact][QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Whiteboard: [3.0-Daily-Testing]
Priority: -- → P2
QA Whiteboard: [rtl-impact][QAnalyst-Triage?] → [rtl-impact][QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
NI Josh to help with nomination and assignment.
Flags: needinfo?(jocheng)
Hi Delphine,
Could you help to triage whether we should nominate this as blocker? Thanks!
blocking-b2g: --- → 2.2?
Flags: needinfo?(jocheng) → needinfo?(lebedel.delphine)
Hey Josh - FWIW I would nominate this as a blocker, as there is really no space at all between the email and the date. This will be an issue in many cases
Flags: needinfo?(lebedel.delphine)
Adding Firefox UX so they can advise on how to move forwards with this
Flags: needinfo?(firefoxos-ux-bugzilla)
We can help once we know why this is happening. Is this an issue with string length? Why is the usual padding being overrun here? Thanks!
Adding QAwanted to get more details about why this is happening, as per comment 7
FWIW I remember talking with Ahmed about this, and him saying that this happened because of the ellipsis at the end of too long LTR emails.
Keywords: qawanted
Assignee: nobody → jrburke
Comment on attachment 8575713 [details] [review]
[gaia] jrburke:bug1135931-email-rtl-space > mozilla-b2g:master

The issue was a -moz-padding-start, which I do not think plays well with the more recent move to flexbox layout for accessibility reasons. So this fix is explicit about the padding parts.

Just a CSS change. Confirmed on device by typing long text via WebIDE into the fields, and confirming the small space is still there in LTR and RTL modes.
Attachment #8575713 - Flags: review?(bugmail)
Flags: needinfo?(firefoxos-ux-bugzilla)
Attachment #8575713 - Flags: review?(bugmail) → review+
Keywords: checkin-needed
Closed: 6 years ago
Resolution: --- → FIXED
Comment on attachment 8575713 [details] [review]
[gaia] jrburke:bug1135931-email-rtl-space > mozilla-b2g:master

[Approval Request Comment]

[Bug caused by] (feature/regressing bug #):
I believe it was an interaction of the -moz-padding-start in bug 1064617 comment 11, and flexbox changes done in bug 1068699, both of which are on 2.2 already.

[User impact] if declined:
Crowded UI in RTL.

[Testing completed]:
On device, trying long strings in LTR and RTL mode.

[Risk to taking this patch] (and alternatives if risky):
Very low, just a CSS change.

[String changes made]:
Attachment #8575713 - Flags: approval-gaia-v2.2?
blocking-b2g: 2.2? → 2.2+
Attachment #8575713 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Attached image 2016-03-17-10-22-04.png
This issue has been verified successfully on Flame 2.2/3.0, there is a space between long sender names and dates after change the date on the dut to a date that is a year from now.
See attachment:2016-03-17-10-22-04.png

Flame 2.2 build: pass
Build ID               20150316162504
Gaia Revision          d0e09d5e6367e558824f9cbf691da99cedf63037
Gaia Date              2015-03-16 17:14:22
Gecko Revision
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150316.195035
Firmware Date          Mon Mar 16 19:50:48 EDT 2015
Bootloader             L1TC000118D0

Flame 3.0 build: pass
Build ID               20150316160204
Gaia Revision          4868c56c0a3b7a1e51d55b24457e44a7709ea1ae
Gaia Date              2015-03-14 18:50:17
Gecko Revision
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150316.193248
Firmware Date          Mon Mar 16 19:32:58 EDT 2015
Bootloader             L1TC000118D0
QA Whiteboard: [rtl-impact][QAnalyst-Triage+] → [rtl-impact][QAnalyst-Triage+][MGSEI-Triage+]
Test case has been added in moztrap:
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.