Closed Bug 1137546 Opened 5 years ago Closed 4 years ago

[RTL][Dialer] With no contacts message that appears when adding call information from dialer to existing contact shows placeholder text

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(b2g-v2.2 affected, b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: bzumwalt, Unassigned)

References

()

Details

(Whiteboard: [3.0-Daily-Testing], [2.5-rtl-test-run])

Attachments

(3 files)

Attached file Logcat
Description:
With language set to Arabic, while user has no contacts on phone, type any number in dialer app then press add to contact button. If user selects add to existing contact they are given expected error message. If they then try to add to existing contact again from dialer they are given a message in English "Confirmation message" with a button that says "Action 1". Selecting this button performs confirm/cancel action returning user to dialer page.

This issue does not occur if language is set to an LTR language.

This issue may take more than one run through of the steps to reproduce (2 to 4), but once the issue reproduces once, the issue reproduces 100% of the time until the device is rebooted.


Repro Steps:
1) Update a Flame to 20150226010233
2) Set language to Arabic
3) Launch Dialer app
4) Type any number
5) Tap add contact button in lower right
6) Select Add to existing contact (with no existing contacts present on device)
7) Tap to confirm on error message and repeat steps 5 - 6

Actual:
Placeholder confirmation screen appears in English "Confirmation message" with button that says "Action 1".

Expected:
Correct error message and button text is displayed.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150226010233
Gaia: 7894b929f1b0394f3c997f72a6482bc7813e758d
Gecko: dd6353d61993
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 39.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Notes: Once issue appears the repro rate is 100%

Repro frequency: 4/4, 100%
See attached: Youtube video clip & logcat
Youtube video link: http://youtu.be/7RYmj7oYP2I
Issue DOES reproduce on Flame 2.2

Placeholder confirmation screen appears in English "Confirmation message" with button that says "Action 1".

The number of times user must repeat steps 5-7 appears to be 3. On the third time the issue presents itself.

Device: Flame 2.2
Build ID: 20150226002503
Gaia: bf24aa57fa7760260ab05d1f53242c8d8ae59e83
Gecko: 363123044e61
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage?][rtl-impact]
Flags: needinfo?(ktucker)
I could only reproduce this using a RTL language. 

Nominating 2.2? because this is a confusing placeholder menu that appears when trying to add a number as a contact in dialer. This could impact and confuse many end users.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?][rtl-impact] → [QAnalyst-Triage+][rtl-impact]
Flags: needinfo?(ktucker)
This looks to me like a race condition, we need to repeat the process several times to get that result.

Also changing the component to contacts, since the problem appears in this application despite that the action stars in dialer.
Component: Gaia::Dialer → Gaia::Contacts
triage: the repro steps are more like edge cases. Decision = non-blocking
blocking-b2g: 2.2? → ---
Priority: -- → P3
Hi William,
According to the STR in comment 0, this issue can be reproduced on latest Flame 2.2&3.0 and Nexus5 2.2&3.0 build, the Placeholder confirmation screen appears in English.
Could you have someone to help with this bug? Many thanks!
See attachment:Placeholder confirmation screen.mp4
Device information:
Flame 2.2 Build ID:20150527002504
Flame 3.0 Build ID:20150527160204
Nexus5 2.2 Build ID:20150527002504
Nexus5_3.0 Build ID:20150527160204
Flags: needinfo?(whsu)
QA Whiteboard: [QAnalyst-Triage+][rtl-impact] → [QAnalyst-Triage+][rtl-impact][MGSEI-Triage+]
Hi, everyone,

We found a similar issues on contact app of v3.0.
Bug 1163732. FYI.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The similar errors show on logs. FYI.

@ Error log from comment 0
02-26 17:40:21.821  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:21.821  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:21.821  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:21.821  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:21.821  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:21.821  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:22.301  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:22.301  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:22.311  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:22.311  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:22.311  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:22.311  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)
02-26 17:40:22.321  1447  1447 W Communications: Content JS WARN: L10nError: "#type_l10n_id#" not found in en-US in app://communications.gaiamobile.org/contacts/index.html?update 
02-26 17:40:22.321  1447  1447 W Communications:     at reportMissingEntity (app://communications.gaiamobile.org/contacts/gaia_build_defer_index.js:179:1907)


@ Bug 1163732
W/Communications( 1267): Content JS WARN: L10nError: "connectingEllipsis" not found in en-US in app://communications.gaiamobile.org/contacts/index.html 
W/Communications( 1267):     at reportMissingEntity (app://communications.gaiamobile.org/shared/js/l10n.js:2115:9)
W/Communications( 1267): Content JS WARN: L10nError: "emergencyDialogBtnOk" not found in en-US in app://communications.gaiamobile.org/contacts/index.html 
W/Communications( 1267):     at reportMissingEntity (app://communications.gaiamobile.org/shared/js/l10n.js:2115:9)
W/Communications( 1267): Content JS WARN: L10nError: "emergencyDialogTitle" not found in en-US in app://communications.gaiamobile.org/contacts/index.html 
W/Communications( 1267):     at reportMissingEntity (app://communications.gaiamobile.org/shared/js/l10n.js:2115:9)
W/Communications( 1267): Content JS WARN: L10nError: "emergencyDialogBodyBadNumber" not found in en-US in app://communications.gaiamobile.org/contacts/index.html 
W/Communications( 1267):     at reportMissingEntity (app://communications.gaiamobile.org/shared/js/l10n.js:2115:9)
W/Communications( 1267): Content JS WARN: L10nError: "emergencyDialogBtnOk" not found in en-US in app://communications.gaiamobile.org/contacts/index.html 
W/Communications( 1267):     at reportMissingEntity (app://communications.gaiamobile.org/shared/js/l10n.js:2115:9)
Flags: needinfo?(whsu)
See Also: → 1163732
Yup, probably a dupe.
This issue can be reproduced on AriesKK-v2.5, add it to RTL block first, if it is dup or not RTL problem, we can remove it again.

Device: AriesKK_v2.5
Build ID               20150810201912
Gaia Revision          fa89e03dc489e79baa0e74cb1d205260c7924caa
Gaia Date              2015-08-10 10:07:57
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3f135a8ead22
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150810.194258
Firmware Date          Mon Aug 10 19:43:05 UTC 2015
Bootloader             s1
This issue still can be reproduced on latest AriesKK v2.5 build but cannot be reproduced on latest FlameKK v2.5 build by the same STR in comment 0.

FlameKK v2.5 build ID (512mb):20151029150245
AriesKK v2.5 build ID: 20151030012032
Depends on: 1181927
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing], [2.5-rtl-test-run]
QA Contact: augustin.trancart
Assignee: nobody → augustin.trancart
QA Contact: augustin.trancart
Status: NEW → ASSIGNED
That's very strange:
- In English, the msg of the confirm string is always translated
- In Arabic or French or any other language, the msg is not translated. But the key is there in the loca files.
- if you switch to settings and change language just after step 6/ *then* the string gets translated. I guess the "localized" event then fires the translation.

So I *think* it is maybe a l10n.js issue, or a wrong use of l10n lib. It is kind of difficult to know, because both the caller and the callee of the activity are in the "communications" app: it's then virtually impossible to debug the callee part, because it does not appear in the WebIDE before being executed :-(

Zibi WDYT? The relevant parts is in shared/js/confirm.js:70

I unassign myself, as it is not a RTL issue anyhow. Feel free to NI or assign me back if the problem is in the application, I may be able to fix it anyway.
Assignee: augustin.trancart → nobody
Status: ASSIGNED → NEW
I was able to reproduce it on flame master. I'll take it and try to debug, but I'm not so sure if it's l10n related.
Assignee: nobody → gandalf
It seems like the condition race is caused by a significant amount of missing translations caused by '#type_l10n_id#' - that in turns makes l10n.js attempt to load a fallback language to translate this ID and that fails so in the end localization never completes.

I was planning to take on communications l10n refactoring anyway, so I can probably start from this template problem.
Actually, I don't have enough knowledge to do that.

What needs to happen is here: 
 - https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/views/details.js#L481-L483

we need to stop attempting to localize everything and instead have a list of types that we know we have entities for and do:

if (l10nTypes.include(type)) {
  element.setAttribute('data-l10n-id', type + '_label');
} else {
  element.textContent = type;
}

and then we have to do the same here: https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/views/form.js#L545-L548 - with the advantage that it seems that we already know which types are localizable.

Because we do localize document, we can't have in document's DOM tags with "data-l10n-id="#type_l10n_id#".

Can you help me find someone to work on that? I'll be happy to co-author the patch, I just don't have the knowledge of Contacts code.
Assignee: gandalf → nobody
Flags: needinfo?(francisco)
Sorry for the late response, the list of items that we try to localize is in the following file:

https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/contacts/js/tag_options.js

(and sorry again!)
Flags: needinfo?(francisco)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.