Closed Bug 1037637 Opened 11 years ago Closed 11 years ago

[DSDS][Dialer] No text on "select SIM" prompt for outgoing calls

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(b2g-v2.0 unaffected, b2g-v2.1 affected)

RESOLVED FIXED
Tracking Status
b2g-v2.0 --- unaffected
b2g-v2.1 --- affected

People

(Reporter: theo, Assigned: zbraniecki)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached image Screenshot, en-US 2.1
1. Get 2 SIMs 2. Go to Settings, SIM Manager and set "Always ask" for outgoing calls 3. Open Dialer, enter a phone number then Tap on phone icon Actual result: See screenshot, no text on the prompt. Expected result: Localized text. If you switch locale while the Dialer App is running, text appear, but it adds an additional "SIM 1" button. Tested on Flame 2.1: Gaia c47094a26c87ba71a3da4bae54febd0da21f3393 Gecko https://hg.mozilla.org/mozilla-central/rev/1b1296d00330 BuildID 20140711040202 Version 33.0a1 ro.build.version.incremental=eng.cltbld.20140710.103658 ro.build.date=Thu Jul 10 10:37:08 EDT 2014
2.0 not affected, sounds like we got a regression here.
QA Contact: ckreinbring
blocking-b2g: --- → 2.1?
Regression window: Last working Build ID: 20140618124932 Gaia: 336c30b6147cdd9122ad0b2bbffb81eb869a9ec2 Gecko: b83f5f1d25b4 Platform Version: 33.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken Build ID: 20140618130034 Gaia: 82e957160ca017087bd374cd051339e55b641e68 Gecko: 00d973a0bdbf Platform Version: 33.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Working Gaia / Broken Gecko = OK Broken Gaia / Working Gecko = Fail Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/336c30b6147cdd9122ad0b2bbffb81eb869a9ec2...82e957160ca017087bd374cd051339e55b641e68 B2G-Inbound regression window: Last working Build ID: 20140618045314 Gaia: c10d115b60992bbd66c51bca5a2454c00c9221e4 Gecko: 72d4f3a1c85a Platform Version: 33.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 First broken Build ID: 20140618052234 Gaia: 809dd6a14aa699328cd9f14c78bf6533fb196622 Gecko: 4fe79d16c180 Platform Version: 33.0a1 Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 Working Gaia / Broken Gecko = OK Broken Gaia / Working Gecko = Fail Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/c10d115b60992bbd66c51bca5a2454c00c9221e4...809dd6a14aa699328cd9f14c78bf6533fb196622
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
broken by bug 992473?
Blocks: 992473
Flags: needinfo?(jmitchell) → needinfo?(gandalf)
Can't really figure out what's going on, but a new button is added at each language change (it->en->it, I have 4 buttons, 2 for each SIM), so it seems we keep calling _buildDom even if the DOM it's already there.
taking
Assignee: nobody → gandalf
Flags: needinfo?(gandalf)
reproduced
Status: NEW → ASSIGNED
Blocks: 1020137
Attached file pull request
Ok, it was actually easier than I thought. Previously mozL10n.localize was translating content manually. We turned it off in 2.1 at the same time when we turned on Mutation Observer. In a rare case like this, the way HTML code is loaded makes it not covered by MO, so we do need a manual translateFragment until the code is going to be refactored in a way that will make it covered by l10n.js MO. I also removed mozL10n.localize and replaced it with the mozL10n.setAttributes since we're phasing out mozL10n.localize (bug 994519). Douglas: seems that you're the owner of that code. Can you review?
Attachment #8456503 - Flags: review?(drs+bugzilla)
Oh, I also fixed the bug from Comment 5. It was just that the code in mozL10n.ready has been adding new line on each retranslation. I moved it outside of that wrapper.
I updated the patch to update tests, but tbpl didn't trigger new builds yet.
The build is green. Doug, will you have time to look at this or can you redirect to someone who can review this?
Flags: needinfo?(drs+bugzilla)
Yes, it's in my queue.
Flags: needinfo?(drs+bugzilla)
Comment on attachment 8456503 [details] [review] pull request Thanks for this patch, and sorry for the slow review. I left a few small comments on the PR. (In reply to Zibi Braniecki [:gandalf] from comment #8) > In a rare case like this, the way HTML code is loaded makes it not covered > by MO, so we do need a manual translateFragment until the code is going to > be refactored in a way that will make it covered by l10n.js MO. Interesting. I've filed bug 1040922 to deal with this. Do you have any ideas as to how we can structure this such that it does trigger MO? > Douglas: seems that you're the owner of that code. Can you review? I'm not a peer of the dialer, but I chatted with Anthony and he gave me this review, so I'm going to feedback? him.
Attachment #8456503 - Flags: review?(drs+bugzilla)
Attachment #8456503 - Flags: review+
Attachment #8456503 - Flags: feedback?(anthony)
(In reply to Doug Sherk (:drs) from comment #13) > Interesting. I've filed bug 1040922 to deal with this. Do you have any ideas > as to how we can structure this such that it does trigger MO? I have to admit that I don't fully understand how is it possible that it is not covered by MO. Would love to understand what's going on with those lazy fragment loads here.
Attachment #8456503 - Flags: feedback?(anthony) → feedback+
Depends on: 1054185
blocking-b2g: 2.1? → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: