MD Settings: CrOS: Add secondary user banner

chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc

Index: chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
diff --git a/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc b/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
index d429ad0fdee2366a0d47111b70961215dbe6a5a9..fb55a1ff7689f59fba8c5730a3127c177d938a6b 100644
--- a/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
+++ b/chrome/browser/ui/webui/settings/md_settings_localized_strings_provider.cc
@@ -997,11 +997,15 @@ void AddMultiProfilesStrings(content::WebUIDataSource* html_source,
   const user_manager::User* user =
       chromeos::ProfileHelper::Get()->GetUserByProfile(profile);
   const user_manager::User* primary_user = user_manager->GetPrimaryUser();
-  html_source->AddString("primaryUserEmail",
-                         primary_user->GetAccountId().GetUserEmail());
+  std::string primary_user_email = primary_user->GetAccountId().GetUserEmail();
+  html_source->AddString("primaryUserEmail", primary_user_email);
   html_source->AddBoolean(
       "isSecondaryUser",
       user && user->GetAccountId() != primary_user->GetAccountId());
+  html_source->AddString(
+      "secondaryUserBannerText",
+      l10n_util::GetStringFUTF16(IDS_SETTINGS_SECONDARY_USER_BANNER,
+                                 base::ASCIIToUTF16(primary_user_email)));

[dschuyler, 2017/02/11 02:54:56]

I believe this will be converted back to UTF8 again. Is it reasonable to keep
this in utf8 rather than converting back and forth?

[stevenjb, 2017/02/13 18:28:00]

It's not UTF8, this is all UTF16.

[dschuyler, 2017/02/13 21:37:09]

Maybe I'm missing something(?). It looks like primary_user_email is converted
from ascii(utf8) to utf16 here on line 1008; then it's passed so AddString which
internally converts back from utf16 to utf8 on line 119 in
web_ui_data_source_impl.cc. (The secondary path on line 118 in
web_ui_data_source_impl.cc converts from utf16 to utf8 on line 160 within
values.cc).

I accept that converting strings is fairly fast, but doing it here and elsewhere
can add up -- it's a trend I'm trying to turn the other way (into doing fewer
conversions). It's not easy to see how many conversions are happening, so I'm
trying to highlight that (or if I'm wrong, I'd like to find out where and how).

[stevenjb, 2017/02/13 21:58:27]

While you are not wrong, that seems like something we should address in general
and not in this CL? Or do you have a specific suggestion here that would be
better that I am missing? Combining the strings in C++ is almost certainly going
to be faster than doing so in JS, conversion or no.

 }
 #endif