1152475 - [RTL][Contacts] Contacts app will remain in RTL layout when switching to English

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1)

Description

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Contacts RTL Logcat

Description:
When switching from a right to left layout, back to a left to right layout with the contacts app open the app will not switch back to the appropriate layout. The app will remain in RTL layout until the app is force closed and re opened

Prerequisite: Have at least 1 contact in the Contacts app

Repro Steps:
1) Update a Flame to 20150408010203
2) Change the language to Arabic
3) Open Contacts app> Tap on a contact
4) Open Settings app> Languages> Change to English
5) Open Contacts app> Tap a contact


Actual:
The contacts app will still display with RTL layout, despite being switch back to Engish, which is an LTR language


Expected:
The Contacts app will always switch to the proper layout (RTL, or LTR) depeding on the set language


Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150408010203
Gaia: 84cbd4391fb7175d5380fa72c04d68873ce77e6d
Gecko: 078128c2600a
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Repro frequency: 10/10
See attached: Logcat, Video - https://youtu.be/j2L2FjSf64w

Comment 1

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

This issue does NOT occur on Flame 2.2

The Contacts app will always switch to the proper layout (RTL, or LTR) depeding on the set language

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150408002503
Gaia: ea735c21bfb0d78333213ff0376fce1eac89ead6
Gecko: 43041c78052b
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Search bar Wrong Language

Also when reproducing this bug, the search bar on the contacts landing page will still be translated to Arabic, even when the device is set to english. This issue persists even after a device restart.

Comment 3

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Layout Regression of a supported feature. Comment 2 dictates restart doesn't fully recover.

Requesting a window.

Comment 4

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

I'm guessing that this not only happens in RTL feature and language, but also the language will not switch when trying in other LTR languages. 
Derek: can you please confirm what happens when you switch from an LTR language to another, suing the same STRs?
Also, I think this might be a dupe of a more general bug, but need to find it :)

Comment 5

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

Gandalf: can you take a look at this please? thanks!

Comment 6

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Delphine: I tried switching to Italian, French, German, And posish as my LTR language, and the bug did not occur. This bug only seems to be occuring when switching to English. I tried using Hebrew as the RTL language, and it too only worked when switching to English.

Comment 7

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

Thanks for the heads-up Derek!

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can you reproduce it in Mirrored English pseudolocale? Arabic is not ready for 3.0 yet and it contains a mix o english and arabic (rtl and ltr) strings, which may result in funny bugs.

Comment 9

[Johan Lorenzo [:jlorenzo]]

Attachment: git bisect log (points to a wrong commit)

I tried to bisect the issue (see attached bisection log) and the result I have doesn't make sense.

I think we're hitting a particular memory issue when we change the language while the app is open. That is to say: When you switch back to English, the application doesn't take into account the changes on a low memory device. That's what we see in the logcat:

> 04-08 15:05:23.058  2548  2548 W Communications: [JavaScript Warning: "Will-change
> memory consumption is too high. Surface area covers 797070 pixels, budget is the
> document surface area multiplied by 3 (172480 pixels). All occurences of will-change
> in the document are ignored when over budget." {file: "app://communications.gaiamobile.org/contacts/index.html" line: 0}]

Before blocking one release on it, I would like to be sure this issue happens only because of memory consumption, and that would explain why we don't see it on 2.2, and why the bisection went wrong. Derek, could you check:

1. If the issue disappear after killing the app an reopening it again? (Contacts gets back to normal from my side)
2. If the issue disappear on a device with 512MB of RAM?

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

I doubt it has anything to do with memory. I tested it in Mirrored English (which is a RTL pseudolocale) and it switched properly.

My suspicion is that the bug exist because it has been tested against an incomplete localization (Arabic) instead a complete pseudolocalization (Mirrored English).

Comment 11

[Johan Lorenzo [:jlorenzo]]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #10)
I'm not sure about your hypothesis.
During the bisection, I built gaia with [1]. The locales had not been modified between each build. Hence, with the same locale, I had different results.

I also checked on 512MB, I couldn't repro. The contact app doesn't get entirely white like shown on the video.

I verified Mirrored English on a 319MB device and I could get in the same state as Arabic. I think the reason it doesn't show up on your device is because it might not be configured as a low memory one. One way to make sure is to reboot in fastboot mode and run [2] and see if it shows:
> mem: 319m

Fernando, do you know how we could get rid of the error in comment 9?

[1] PRODUCTION=1 MOZILLA_OFFICIAL=1 LOCALE_BASEDIR=$PWD/locales LOCALES_FILE=./locales/languages_all.json GAIA_KEYBOARD_LAYOUTS=en,pt-BR,es,de,fr,pl,zh-Hans-Pinyin,zh-Hant-Zhuyin,en-Dvorak,ar make install-gaia

[2] fastboot getvar mem

Comment 12

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #9)
> 1. If the issue disappear after killing the app an reopening it again?
> (Contacts gets back to normal from my side)
> 2. If the issue disappear on a device with 512MB of RAM?

Johan: Yes, if the app is killed and then reopened this issue will go away. Also after several attempts to reproduce this bug on 512mb memory I was unable to reproduce. This seems to be an issue that only occurs on 319mb memory

Comment 13

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #11)
> Fernando, do you know how we could get rid of the error in comment 9?

Sorry, no idea. CSS and me are not best friends. Maybe Francisco has a better understanding of this. FWIW  the warning was added on bug 1092320 and we are using "will-change" here https://mxr.mozilla.org/gaia/search?find=%2Fapps%2Fcommunications%2Fcontacts%2F&string=will-change

Comment 14

[Johan Lorenzo [:jlorenzo]]

The memory footprint on the current 2.2[1] is lower, I couldn't reproduce the bug after 5 tries.

Comms triage: Bug breaking the user experience on 3.0 against low memory devices.

[1] Build ID               20150519002500
Gaia Revision          732acec6f37d13ccea6b0ddc48904a53a2970894
Gaia Date              2015-05-19 06:24:24
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1389e6b8c065
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150519.035534
Firmware Date          Tue May 19 03:55:45 EDT 2015
Bootloader             L1TC000118D0

Comment 15

[Pi Wei Cheng [:piwei] (inactive)]

Adding regression keyword since 2.2 is unaffected.

Comment 16

[Lancy(Leave from Mozilla)]

Attachment: AriesKK_V2.5.3GP

This issue cannot be reproduced on latest Aries KK v2.5 build by the same STR in comment 0.
Actual Result:
The Contacts app will always switch to the proper layout (RTL, or LTR) depeding on the set language.
See attachment:AriesKK_V2.5.3GP.
Reproducing rate:0/10

Device: Aries KK v2.5 build
Build ID               20150810003528
Gaia Revision          09dea2d5ff21cdb56da35fe4aa5bf4c90cf1da7f
Gaia Date              2015-08-09 17:11:47
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/0e269a1f1beb
Gecko Version          42.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150810.000017
Firmware Date          Mon Aug 10 00:00:24 UTC 2015
Bootloader             s1


But still exist on latest Flame KK v2.5 build by the same STR in comment 0.
Actual Result:
The contacts app will still display with RTL layout, despite being switch back to Engish, which is an LTR language.

Device: Flame KK v 2.5 build
Build ID               20150810150206
Gaia Revision          9a8880a95ee4a4aea7895d4e2bcab31bc49ea281
Gaia Date              2015-08-10 16:01:11
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/8cba870a352c
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150810.183734
Firmware Date          Mon Aug 10 18:37:46 EDT 2015
Bootloader             L1TC000118D0

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can you verify if you have the same locales on Flame KK build and Aries KK build?

I still suspect that you are testing an incomplete localization on Flame.

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #11)
> (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #10)
> I'm not sure about your hypothesis.
> During the bisection, I built gaia with [1]. The locales had not been
> modified between each build. Hence, with the same locale, I had different
> results.

True, but for 2.2 you were testing against more complete locale than when you tested against master. Because the locale has been done for 2.2.
We've also changed a lot of l10n.js library so our edge case behavior for handling RTL/LTR mixes on missing strings may be different between 2.2 and 2.5.

What I'm arguing is that testing an incomplete locale is a bad way to test RTL. Unfortunately by the nature of things, that means that you can't test RTL using a real localization on master until localization phase. That's why we have pseudolocale and we should use it until we have one of the RTL localizations completed for the given release and we can test it.

Comment 18

[Francisco Jordano [:arcturus] [:francisco]]

With the current app model with different documents I'm seeing an weird effect. The contact detail that is in a different page changes the html lang attribute but the list that is in a different page, and getting back to live from the bfcache is not receiving any event.

So with the new architecture we will need to propagate any language across the different views to be sure the language didn't chage (language, language direction, etc).

Now if I take a look to the video, this was taken before we have views separated. So will need to reproduce this again once we have in master the reversion of the changes for splitting views.

Comment 19

[Francisco Jordano [:arcturus] [:francisco]]

Good news is, when I tried with the reverted branch this doesn't happen anymore.

Comment 20

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #18)
> So with the new architecture we will need to propagate any language across
> the different views to be sure the language didn't chage (language, language
> direction, etc).

The NGA localization API - l20n.js will actually do this for you. We designed the new API to handle multi-View model and we have corresponding l10n Views that are synchronized between each other. Each l10n View may be a different View document, an iframe, or shadow DOM within a web component.

We'd love to move Contacts to L20n.js soon.

Comment 21

[Maria Angeles Oteo (:oteo)]

After reverting the commits that gave us separated views in Contcats (as part of the NGA work) the issue reported on this bug is not happening anymore in master (as Francisco confirms in comment 19).

For that reason, removing the 2.5+ flag and adding [only for NGA Contacts branch] whiteboard to ensure that this bug need to be fixed in NGA branch (but not in current master branch)

Comment 22

[Sam Foster [:sfoster] (he/him)]

Not sure if this is still valid, but unblocking on RTL/v2.5 as it does not apply to that branch.

Comment 23

[BMO Automation]

Firefox OS is not being worked on