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

Status: VERIFIED FIXED

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

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

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

Prerequisite:
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.

Actual:
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. 

Expected:
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

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: CorrectspacethennospaceLogcat.txt

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

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

Comment 3

[Teri Wen [:twen]]

NI Josh to help with nomination and assignment.

Comment 4

[Josh Cheng [:josh]]

Hi Delphine,
Could you help to triage whether we should nominate this as blocker? Thanks!

Comment 5

[Delphine Lebédel [:delphine - Use needinfo]]

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

Comment 6

[Delphine Lebédel [:delphine - Use needinfo]]

Adding Firefox UX so they can advise on how to move forwards with this

Comment 7

[Stephany Wilkes]

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!

Comment 8

[Delphine Lebédel [:delphine - Use needinfo]]

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.

Comment 9

[GitHub Autolander Bot]

Attachment: [gaia] jrburke:bug1135931-email-rtl-space > mozilla-b2g:master

Comment 10

[James Burke [: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.

Comment 11

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/99bc420ee8edb75f1c5fae06e799b427242cf0e2

Comment 12

[James Burke [:jrburke]]

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]:
none

Comment 13

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/ff593cf1f4f9b920e007e121909680cd31bc4d19

Comment 14

[Sue]

Attachment: 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
Rate:0/5

Flame 2.2 build: pass
Build ID               20150316162504
Gaia Revision          d0e09d5e6367e558824f9cbf691da99cedf63037
Gaia Date              2015-03-16 17:14:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/793d61bb0bd4
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         https://hg.mozilla.org/mozilla-central/rev/436686833af0
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

Comment 15

[Lancy(Leave from Mozilla)]

Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/16081/