Ref: attachment 8374263 [details]

NI Wilfred and Joe for discussing whether we keep it in 1.4.

move this to backlog

The spec looks fine. Please implement with it.

Hey Zhenshuo, can we have a visual design for this? It's supposed to be part of the visual refresh work for v2.1.

The NI was for the wrong Fang :(

Attached the DSDS message thread visual spec! Thanks!

Stealing ;)

Jenny, just a small question: should the SIM information be written as "SIM 1" or "SIM1"? I think we use "SIM 1" everywhere else. Thanks !

Jenny, another question: should we display the SIM information in these cases: * we have 2 slots but currently 1 SIM * the SIM that originally sent the message is not present anymore. If we should display something, what should we display? Thanks !

Pending answers from Jenny. Current behavior: * uses "SIM 1" form (and not "SIM1") * does not show the information if we have either one SIM only or when the SIM iccId is not found in the current inserted SIM

(In reply to Julien Wajsberg [:julienw] from comment #13) > Created attachment 8472391 [details] > github PR > > Pending answers from Jenny. > > Current behavior: > * uses "SIM 1" form (and not "SIM1") I actually like "SIM 1" better because it's clearer. But I'm seeing quite a few "SIM1" too, ex, observe the dialog appears when long pressing call button from dialer or send button from message. I've talked to Carrie about this and we both agree we should use "SIM 1" in dialer and message (with the exception of call button and send button, we need visual's comment on this). So let's use "SIM 1" :) > * does not show the information if we have either one SIM only or when the > SIM iccId is not found in the current inserted SIM Confirmed don't show SIM information if we have either one SIM only or when the SIM iccId is not found in the current inserted SIM. Thanks!

(In reply to Jenny Lee from comment #14)But I'm seeing quite a > few "SIM1" too, ex, observe the dialog appears when long pressing call > button from dialer or send button from message. I see "SIM 1" in these dialogs too (v2.0, french locale). If you see otherwise on your build this may be a bad locale file or maybe it regressed on master? May be useful to file a separate bug if you see this. Thanks for your other answers !

I've reported this to QA :)

Comment on attachment 8472391 [details] github PR Hey Oleg, I ask a review from you here because I know you already worked on the ThreadUI redesign, so I think you're a good fit. Not a big deal, but please try it on a real device as I used only the simulator ;)

Comment on attachment 8472391 [details] github PR Code wise patch looks good, just left one comment at github. However I still see SIM information on message bubble on Flame with only one SIM inserted. Could you please look into that? Also in spec I see there is one more DSDS related change expected - SIM number previously located at the top of send button moved below it. Is it supposed to be fixed in another VR 2.1 DSDS bug (can't find it)? Thanks!

Comment on attachment 8472391 [details] github PR Filed bug 1054989 for the DSDS Send button refresh, with a WIP patch. Otherwise I think I handled all your comments ! :)

Comment on attachment 8472391 [details] github PR It looks good now! Just tiny nit in unit tests. Thanks!

master: 167b5671ddadb4b5aee06922a077f0d7e734bab0 Thanks !

Verified User story is fixed. SIM info can be viewed in message bubble. Gaia 2be78d83a760fa3b9638fe51c266b442d14597f1 Gecko https://hg.mozilla.org/mozilla-central/rev/1db35d2c9a2f BuildID 20140831160203 Version 34.0a1 ro.build.version.incremental=110 ro.build.date=Fri Jun 27 15:57:58 CST 2014 B1TC00011230

Tested and working Flame 2.1 User Gecko-2fbbb04 Gaia-59bd661

Hey Julien, Here is the v2.0 patch as per request from bug 1102706 comment 16. It modifies original patch in the following way (added as separate commit): * We don't have "sim-id-label" in v2.0, so v2.0 patch uses old "sim-name" that doesn't have space between "SIM" label and SIM number. I guess it's too late to introduce new l10n string; * navigator.l10n.translate(messageDOM) is returned back as we don't use MutationObservers for l10n in v2.0. Thanks!

Comment on attachment 8528973 [details] GitHub pull request URL (v2.0) yep, I tested on my own dogfood phone that's on v2.0 and it works fine :) Thanks !