Closed Bug 1157610 Opened 9 years ago Closed 9 years ago

[RTL][First Time Experience][FxA] The ellipsis is shown at left side of LTR text in EntrySheet headers

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

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

VERIFIED FIXED
2.2 S11 (1may)
blocking-b2g 2.2+
Tracking Status
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: lulu.tian, Assigned: sfoster)

References

Details

(Whiteboard: [2.2-nexus-5-l] [systemsfe])

Attachments

(7 files)

Attached image ellipsis_in_FTE.png
[1.Description]:
[RTL][Flame v2.2 & v3.0][Nexus5 2.2 & 3.0][First Time Experience]The ellipsis is shown at left side of LTR text in hearders when user checks "Terms of Service" or "Privacy Notice".
See attachment:ellipsis_in_FTE.png

[2.Testing Steps]: 
1. Flash device and set system language as Arabic at FTE.
2. Tap "Next" until reaching the "Select a Network" screen.
3. Connect to a network and then tap "Next" until reaching the "Firefox Accounts" screen.
4. Tap "Create Account or Sign In".
5. Tap "Terms of Service" or "Privacy Notice".
6. Observe the ellipsis at headers.

[3.Expected Result]: 
6. The ellipsis should be shown at right side of LTR text.

[4.Actual Result]: 
6. The ellipsis is shown at left side of LTR text.

[5.Reproduction build]: 
Device: Flame 2.2 (affected)
Build ID               20150422162503
Gaia Revision          41a85c5f9db291d4f7c0e94c8416b5115b4ee407
Gaia Date              2015-04-21 17:23:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/367b3e608cd8
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150422.200151
Firmware Date          Wed Apr 22 20:02:02 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 3.0 (affected)
Build ID               20150422160203
Gaia Revision          9d4f756aa35cb7f030a92f3c1f65fb55254ddd1d
Gaia Date              2015-04-22 17:32:36
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/a9311ec2dd39
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150422.193515
Firmware Date          Wed Apr 22 19:35:27 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus 5 2.2 (affected)
Build ID               20150422162503
Gaia Revision          41a85c5f9db291d4f7c0e94c8416b5115b4ee407
Gaia Date              2015-04-21 17:23:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/367b3e608cd8
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150422.195718
Firmware Date          Wed Apr 22 19:57:35 EDT 2015
Bootloader             HHZ12f

Device: Nexus 5 3.0 (affected)
Build ID               20150422010202
Gaia Revision          15134b080b5f406e5aa36f5136c17dafb4e31f64
Gaia Date              2015-04-21 19:52:45
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/946ac85af8f4
Gecko Version          40.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150422.044004
Firmware Date          Wed Apr 22 04:40:22 EDT 2015
Bootloader             HHZ12f

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test
QA Whiteboard: [rtl-impact]
blocking-b2g: --- → 2.2?
Whiteboard: [2.2-nexus-5-l] → [2.2-nexus-5-l] [systemsfe]
Assignee: nobody → sfoster
Triage -- P2. Blocking as this is inconsistent behavior with UX specs
blocking-b2g: 2.2? → 2.2+
Priority: -- → P2
Is this a regression?
Flags: needinfo?(lebedel.delphine)
Correct, I believe this is, since this should have been fixed in Bug 1151925 (and verified on 2015-04-19)
Flags: needinfo?(lebedel.delphine)
Keywords: regression
(In reply to Delphine Lebédel [:delphine - use need info] from comment #3)
> Correct, I believe this is, since this should have been fixed in Bug 1151925
> (and verified on 2015-04-19)

Bug 1151925 is about the URL bar in the browser with full chrome(back buttons...).
This is a simple browser window without any chrome that mostly opens when we navigate from apps other than browser. I assume the same bug happens when we open a link from an email in our email app for example. 
Sue, can we check this use-case?
Flags: needinfo?(lulu.tian)
Sorry, no idea about that. Can't help more I'm afraid.
Attached image 2015-04-23-22-27-16.png
FWIW I tried on 2.2 to open an LTR URL from the email app, and it truncates like it should (on the right). I'll let Sue take it from there, and confirm any other needed steps.
(seems from the screenshot it's not the same browser window though.)
This is the same problem the SMS app fixed in bug 1138340, we should be able to do something similar here. Also adding bug 1140668 as ultimately this is a gaia-header bug.
See Also: → 1140668, 1138340
This issue occurs on Flame 2.2 and Flame 3.0 and I could not find a build where it had worked either before or after bug 1151925 had be fixed so this is NOT a regression.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150423065001
Gaia: 4d87112bbf48cdd09c19e553cc9aebd2a2c4ddfd
Gecko: 10a237997b8d
Version: 40.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Environmental Variables:
Device: Flame 2.2
BuildID: 20150423074202
Gaia: b838d0e7c163e66660dcb6e387d8339944a7a30e
Gecko: 5fe76b26e55f
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ktucker)
Keywords: qawanted, regression
QA Whiteboard: [rtl-impact] → [rtl-impact][QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Attached image verified_email.png
I cannot repro this issue in email app on Flame 2.2/3.0. I have sent a URL link from a long name email address to test device, and the long name in email app is shown correctly and when I open the the URL link from an email, the link is shown correctly.
See attachment: verified_email.png
Rate:0/3
Flags: needinfo?(lulu.tian) → needinfo?(anygregor)
QA Whiteboard: [rtl-impact][QAnalyst-Triage+] → [rtl-impact][QAnalyst-Triage+][MGSEI-Triage+]
Turns out this is the titles of the EntrySheets FxA creates for its external links. Again, this is really bug 1140668, but we'll need a workaround in the interim.
Summary: [RTL][First Time Experience]The ellipsis is shown at left side of LTR text in hearders. → [RTL][First Time Experience]The ellipsis is shown at left side of LTR text in FxA headers.
Comment on attachment 8597533 [details] [review]
[gaia] sfoster:entrysheet-headers-bug-1157610 > mozilla-b2g:master

Firefox Accounts and Captive Portal use an EntrySheet instance to display remote content (they are the only users I could find). The gaia-header and h1 that contains the sheet title needs to observe the document direction for the positioning of the title and close button (i.e. [x] title for RTL, title [x] for LTR) but truncate the title contents appropriately for the content themselves - which could be either direction. 

In practice, FxA and CaptivePortal provide the url to display as title, so I've prefixed that with the LEFT-TO-RIGHT Mark where that gets passed in, to ensure the bidi algorithm does the right thing. I've tested putting arabic script in there and the direction and truncation flip correctly. 

I could use input on if/how we should cover this stuff in automated testing. I think we've punted on testing a lot of these bidi fixes to-date, but I guess it would need to be a marionette-js test to get accurate getComputedStyle().direction value for the nested gaia-header contents. I know of no way apart visual or ref-test to determine if the title gets truncated correctly. 

Also, we have STR for the FxA screens, but the captive portal screen is harder to bring up manually if you don't have one handy. From the WebIDE, during the FTE, in the system app I did: 

// if running FTU from WebIDE or developer settings, you'll need to: 
FtuLauncher.isFtuRunning = function() { return true; };

CaptivePortal.handleEvent(new CustomEvent('mozChromeEvent', { detail: {
      type: 'captive-portal-login',
      url: 'http://developer.mozilla.org',
      id: 0
}}));

..and that kinda worked well enough to show me I'd not broken anything and the title got truncated correctly. I could break that part of the patch out, but as the patch needs to touch entry_sheet.js, it seems like the captive portal usage should be fixed up at the same time.
Attachment #8597533 - Flags: review?(kgrandon)
Comment on attachment 8597533 [details] [review]
[gaia] sfoster:entrysheet-headers-bug-1157610 > mozilla-b2g:master

I'm unable to thoroughly test this due to the captive portal thing, might want to have QA take a look to verify this. Patch seems simple enough though that I don't mind dropping an R+ here. Thanks.
Attachment #8597533 - Flags: review?(kgrandon) → review+
Flags: needinfo?(anygregor)
Target Milestone: --- → 2.2 S11 (1may)
Lets land this and get verification before requesting uplift. Naoki, you said in #gaia you have the wherewithall to test this properly?
Flags: needinfo?(nhirata.bugzilla)
Keywords: checkin-needed
Changing title - EntrySheet is used by external links in FxA setup screens linked from FTU, and for captive portal login screens.
Summary: [RTL][First Time Experience]The ellipsis is shown at left side of LTR text in FxA headers. → [RTL][First Time Experience][FxA] The ellipsis is shown at left side of LTR text in FxA headers.
Summary: [RTL][First Time Experience][FxA] The ellipsis is shown at left side of LTR text in FxA headers. → [RTL][First Time Experience][FxA] The ellipsis is shown at left side of LTR text in EntrySheet headers
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
autolander popped it into master.

updated my gaia with the latest repo + ar ( git clone http://git.mozilla.org/releases/l10n/ar/gaia.git ar )
It seems fixed.  Need to wait for official build.

Note: https://bugzil.la/1088461 ; if you look at the privacy pages after the accounts ( not the same page, the one following ), you can get stuck in the FTU browser.
Flags: needinfo?(nhirata.bugzilla)
No longer depends on: 1159906
According to the STR in comment 0, this issue is verified pass on latest Flame 3.0 and Nexus_5 3.0 build, the ellipsis is shown at right side of LTR URL.

See attachment:Verify1_Flame 3.0&N5 3.0_Pass.png
Reproducing rate:10/10

Flame 3.0 build:
Build ID               20150429010205
Gaia Revision          6e35b0948c42a4398b8a5916015de167121683a1
Gaia Date              2015-04-28 16:06:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150429.043837
Firmware Date          Wed Apr 29 04:38:48 EDT 2015
Bootloader             L1TC000118D0

Nexus_5 3.0 build:
Build ID               20150429010205
Gaia Revision          6e35b0948c42a4398b8a5916015de167121683a1
Gaia Date              2015-04-28 16:06:07
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1ad65cbeb2f4
Gecko Version          40.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150429.044325
Firmware Date          Wed Apr 29 04:43:46 EDT 2015
Bootloader             HHZ12f
Flags: needinfo?(nhirata.bugzilla)
Attached image 2015-04-30-14-00-20.png
FYI.  Verified in a portal as well. (see portal)
Does this need to be rebased for 2.2?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(sfoster)
> FYI.  Verified in a portal as well. (see portal)
> Does this need to be rebased for 2.2?

No, looks like it applies cleanly and works as expected. Thanks for the captive-portal check. I'll request uplift.
Flags: needinfo?(sfoster)
Comment on attachment 8597533 [details] [review]
[gaia] sfoster:entrysheet-headers-bug-1157610 > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): RTL/Bidi content in FTU privacy-policy and captive-portal screens
[User impact] if declined: Titles may get truncated from the wrong end for the title's language in these specific screens
[Testing completed]: Green tests, manual testing on device in both LTR and RTL. Naoki also tested the captive portal change specifically. 
[Risk to taking this patch] (and alternatives if risky): Low risk as the fix is exclusive to the entry sheet uses, which are known and small in number. 
[String changes made]: None
Attachment #8597533 - Flags: approval-gaia-v2.2?
Attachment #8597533 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
This issue has been verified passed on latest build of Flame 2.2 and Nexus 5 2.2 with the same steps in comment 0.
See attachment:verify_flame 2.2 & N5 2.2_pass.png
Rate:0/3

Device: Flame 2.2 (pass)
Build ID               20150503002500
Gaia Revision          8d14361337e608c8cdf165ea5034db5eda23b618
Gaia Date              2015-05-01 18:23:46
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cb7cb6597c91
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150503.040203
Firmware Date          Sun May  3 04:02:15 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus 5 2.2 (affected)
Build ID               20150503002500
Gaia Revision          8d14361337e608c8cdf165ea5034db5eda23b618
Gaia Date              2015-05-01 18:23:46
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cb7cb6597c91
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150503.040229
Firmware Date          Sun May  3 04:02:46 EDT 2015
Bootloader             HHZ12f
Status: RESOLVED → VERIFIED
Test case has been added in moztrap:
https://moztrap.mozilla.org/manage/case/15500/
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: