Closed
Bug 1137546
Opened 10 years ago
Closed 9 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)
Tracking
(b2g-v2.2 affected, b2g-master affected)
RESOLVED
WONTFIX
People
(Reporter: bzumwalt, Unassigned)
References
()
Details
(Whiteboard: [3.0-Daily-Testing], [2.5-rtl-test-run])
Attachments
(3 files)
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
Reporter | ||
Comment 1•10 years ago
|
||
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]
status-b2g-v2.2:
--- → affected
Flags: needinfo?(ktucker)
Comment 2•10 years ago
|
||
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)
Comment 3•10 years ago
|
||
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
Comment 4•10 years ago
|
||
triage: the repro steps are more like edge cases. Decision = non-blocking
blocking-b2g: 2.2? → ---
Updated•10 years ago
|
Priority: -- → P3
Comment 5•10 years ago
|
||
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)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+][rtl-impact] → [QAnalyst-Triage+][rtl-impact][MGSEI-Triage+]
Comment 6•10 years ago
|
||
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
Comment 7•10 years ago
|
||
Yup, probably a dupe.
Comment 8•10 years ago
|
||
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
Comment 9•10 years ago
|
||
Comment 10•9 years ago
|
||
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]
Updated•9 years ago
|
QA Contact: augustin.trancart
Updated•9 years ago
|
Assignee: nobody → augustin.trancart
QA Contact: augustin.trancart
Updated•9 years ago
|
Status: NEW → ASSIGNED
Comment 11•9 years ago
|
||
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
Comment 12•9 years ago
|
||
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
Comment 13•9 years ago
|
||
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.
Comment 14•9 years ago
|
||
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)
Comment 15•9 years ago
|
||
ping?
Comment 16•9 years ago
|
||
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)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•