I think the test shouldn't depend on the locale -- either it should override it, or the code should be locale-agnostic.

This is where the sensitivity comes from, DownloadManager::GenerateFileName.
It's not clear to me it's right to convert our translated string to the system native charset.

  std::wstring default_name =
      l10n_util::GetString(IDS_DEFAULT_DOWNLOAD_FILENAME);
#if defined(OS_WIN)
  FilePath default_file_path(default_name);
#elif defined(OS_POSIX)
  FilePath default_file_path(base::SysWideToNativeMB(default_name));
#endif

Over to jshin, who has been voted "most likely to be able to fix this bug." =)

I raised this issue a long time ago in the mailing list, but haven't followed up since. 

How about making Chrome only run in a UTF-8 locale and making SysNativeMBToWide and SysWideToNativeMB the same as UTF8ToWide and WideToUTF8?  

As for the failure at hand, I guess we just have to set the locale to a UTF-8 locale (e.g. en_US.UTF-8) directly instead of just checking the current locale and bailing out if it's not a UTF-8 locale.

See http://chrome-master.mtv:8010/builders/chrome%20official%20linux/builds/1112/steps/unit_tests/logs/TestDownloadFilename

LANG should be set to UTF-8.  It is set correctly on the linux x64 builder, but not on the "chrome official linux" builder.

(No comment was entered for this change.)