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

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: tchevalier, Assigned: zbraniecki)

Tracking

({regression})

Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(2 attachments)

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
Posted 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.