I am at Version 57.0.2951.0 (Official Build) dev (64-bit) and the issue is still present. 

Running 56.0.2924.53 official build beta, issue also present.

<triage> I do see the hours left on my samus, so this might be device specific.

jaug1337 and rossjrw: can you please clarify which devices you're using (in the 'Google Chrome' line at the top of chrome://version) as well as the Platform version.

Anyone who reliably sees this bug: can you please go to chrome://flags and set the 'ash-md' flag to "Disabled" instead of "Default" to revert back to the non-MD interface and let me know if the bug still reproduces.

I've just reverted to stable 55.0.2883.105 (platform  8872.76.0 (Official Build) stable-channel nyan_big) to work around other issues I was having, and the issue is not present even when ash-md is set to Enabled or Experimental.

I'm not keen on switching back to beta to test disabling ash-md, since stable seems to have fixed all the problems I was experiencing, but if it is device-specific and it would be useful then I can do so at some point.

I'm on 57.0.2970.0 Dev and changing md-ash has no effect. Time remaining is
still absent.

I should clarify that I changed from to default to disabled with no effect.
Thanks

anowlcalledjosh@ and kaingardner@, thanks for the feedback.

I cannot reproduce this on m-56 beta or on m-57 canary, and in looking over the changes made to PowerStatusView as part of the MD rework I don't think any of the UI changes are to blame for this bug. It seems as though it is device-specific, and probably a result of some bug/regression in what the underlying power_manager::PowerSupplyProperties |proto_| field is reporting in the PowerStatus class (specifically it looks like one or both of battery_time_to_empty_sec() and battery_time_to_full_sec() is empty).

Albert, can you please help triage this? Removing the CrOS-MD label.

Possible duplicate:  issue 686875 

derat@ / stevenjb@ / jamescook@, are either of you familiar with power_manager (see comment #9)?

derat@ or +michaelpg@ should know about this.

Please file a feedback report (Alt+Shift+i) or attach file:///var/log/power_manager/powerd.LATEST while you're seeing this so we can see what powerd is telling Chrome.

My guess is that powerd is unable to estimate the battery time-to-empty/full (this is expected at times, due to a e.g. low-power charger being used or the estimate still being calculated), and the MD version of the system area doesn't handle this the same way as the pre-MD version. Specifically, see the logic in ash::PowerStatusView::UpdateText() -- are we still doing all of this?

  if (status.IsBatteryFull()) {
    battery_time_status =
        l10n_util::GetStringUTF16(IDS_ASH_STATUS_TRAY_BATTERY_FULL);
  } else {
    battery_percentage = base::FormatPercent(status.GetRoundedBatteryPercent());
    if (status.IsUsbChargerConnected()) {
      battery_time_status = l10n_util::GetStringUTF16(
          IDS_ASH_STATUS_TRAY_BATTERY_CHARGING_UNRELIABLE);
    } else if (status.IsBatteryTimeBeingCalculated()) {
      battery_time_status =
          l10n_util::GetStringUTF16(IDS_ASH_STATUS_TRAY_BATTERY_CALCULATING);
    } else {
      base::TimeDelta time = status.IsBatteryCharging()
                                 ? status.GetBatteryTimeToFull()
                                 : status.GetBatteryTimeToEmpty();
      if (PowerStatus::ShouldDisplayBatteryTime(time) &&
          !status.IsBatteryDischargingOnLinePower()) {
        battery_time_status = l10n_util::GetStringFUTF16(
            status.IsBatteryCharging()
                ? IDS_ASH_STATUS_TRAY_BATTERY_TIME_UNTIL_FULL_SHORT
                : IDS_ASH_STATUS_TRAY_BATTERY_TIME_LEFT_SHORT,
            TimeDurationFormat(time, base::DURATION_WIDTH_NUMERIC));
      }
    }
  }

The logic of UpdateText() pasted in #13 did not change as part of the material design rework, and combined with comment #7 this leads me to believe it is not a UI issue.

Looking at the screenshot in #0, the time itself is absent but "left" is still present, which means that we're reaching the line where |battery_time_status| is being constructed with IDS_ASH_STATUS_TRAY_BATTERY_TIME_LEFT_SHORT and |time| giving some possible causes:

(1) |time| is being initialized as empty / something erroneous and ShouldDisplayBatteryTime() returns true with this value (when it shouldn't).

(2) The information in |status| is inconsistent with itself, e.g., IsBatteryDischargingOnLinePower() is true when it should be false.

(3) There is a bug in GetStringFUTF16().

(4) There is a bug in TimeDurationFormat(time, base::DURATION_WIDTH_NUMERIC). 

My money is on (4) - a code search reveals issue 675791. cc'ing chengx@ and jshin@ for time-formatting code.

Re-assigning to glevin@ to take a look since I think https://codereview.chromium.org/1951493002 may have caused this regression. That cl starts using base::DURATION_WIDTH_NUMERIC to format the battery time, and there is a comment in time_formatting.h claiming "Please don't use width = DURATION_WIDTH_NUMERIC when the time duration can possibly be larger than 24h, as the hour value will be cut below 24 after formatting."

 Issue 686875  has been merged into this issue.

Re: Comment 15

I am the one who added the comment "Please don't use width = DURATION_WIDTH_NUMERIC when the time duration can possibly be larger than 24h, as the hour value will be cut below 24 after formatting."

Can confirm this is what the time formatting code is doing currently.

glevin@, friendly ping on this issue.

Thanks!  I was out on leave for a couple of weeks, but will try to get to this soon!

The request for filing a feedback report (Alt+Shift+i) while you're seeing this still stands.

#CBC-RS/TC-watchlist

Feedback report submitted. Issue number quoted.

Thanks, the feedback report is at http://feedback/#/Report/53339594746. Just to confirm since a screenshot wasn't attached, did the system tray say something like "28% - left" when you filed the report?

I don't see anything suspicious near the end of powerd.LATEST:

[0215/150009:INFO:daemon.cc(772)] On battery at 30% (displayed as 28%), 1.056/3.496Ah at 0.012A, 0s until empty (calculating)
...
[0215/150014:INFO:daemon.cc(772)] On battery at 30% (displayed as 28%), 1.055/3.496Ah at 0.373A, 2h10m37s until empty (1h53m18s until shutdown)
...
[0215/150044:INFO:daemon.cc(772)] On battery at 30% (displayed as 28%), 1.051/3.496Ah at 0.447A, 2h18m13s until empty (1h59m50s until shutdown)
...
[0215/150113:INFO:daemon.cc(772)] On battery at 30% (displayed as 28%), 1.047/3.496Ah at 0.557A, 2h18m55s until empty (2h21s until shutdown)
...
[0215/150143:INFO:daemon.cc(772)] On battery at 30% (displayed as 28%), 1.042/3.496Ah at 0.721A, 2h7m until empty (1h49m57s until shutdown)

In other words, powerd was sending reasonable-looking time-to-empty estimates to Chrome just before the feedback report was sent.

Sorry about the lack of screenshot.
Yes, it said 28% - left.

Thanks, I think that narrows this down to a UI bug within Chrome.

I can confirm that I have the same issue - Asus ChromeBook Flip 4GB - Beta Mode - Non dev mode

Version 56.0.2924.87 beta
Platform 9000.82.0 (Official Build) beta-channel veyron_minnie
ARC Version 3691121
Firmware Google_Veyron_Minnie.6588.237.0

Screenshot attached

Sometimes it says"

"42% -  left",

other times just

"42%"

Deleted: Screenshot 2017-02-20 at 8.44.51 PM.png 6.9 KB

	Screenshot 2017-02-20 at 8.44.51 PM.png 6.9 KB View Download

Charger plugged in - just the %

On battery - % with time left

Version 56.0.2924.101 (64-bit)
Platform 9000.87.0 (Official Build) stable-channel auron_yuna
ARC Version 3731316
Firmware Google_Auron_yuna.6301.59.8

Deleted: Screenshot 2017-02-20 at 12.37.55 PM.png 3.4 KB

	Screenshot 2017-02-20 at 12.37.55 PM.png 3.4 KB View Download

Deleted: Screenshot 2017-02-20 at 12.38.20 PM.png 3.8 KB

	Screenshot 2017-02-20 at 12.38.20 PM.png 3.8 KB View Download

 Issue 693831  has been merged into this issue.

Hi, i am facing the same issue, the battery tiume dissappeared suddenly, even without me updating the OS, i am now on latest build and have a Toshiba Chromebook 2.

Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel swanky
Firmware Google_Swanky.5216.238.5

Thanks
Amer

I am also getting this issue as of the most recent update. 


Google Chrome	56.0.2924.110 (Official Build) (64-bit)
Revision	0
Platform	9000.91.0 (Official Build) stable-channel gnawty

Device: Acer Chromebook 11 (CB3-111)

@glevin can you please look into this for M58?

We have a major enterprise customer reporting this issue, can we get eyes on?

For users experiencing this issue, can you open the crosh shell with CTRL+ALT+T and run:

battery_firmware info
battery_firmware check
battery_test

and post results of each command? Last command may take 5 minutes to run (discharge test).

#34: Per #23, powerd is sending reasonable-looking time-to-empty estimates to Chrome. That's the only input to the UI, so I suspect that this bug lives in the UI. There's no way that a battery firmware issue can be responsible for Chrome displaying " left", because " left" is nonsensical and Chrome shouldn't be capable of displaying it in the first place.

battery_firmware info
Target program '/usr/sbin/ectool' is not accessible.

battery_firmware check
Target program '/usr/sbin/ec_sb_firmware_update' is not accessible.

battery_test
No test length specified. Defaulting to 300 seconds.
Battery is discharging (10.84% left)
Battery health: 102.60%
Please wait...
Battery discharged 0.00% in 300 second(s).

ran test again

No test length specified. Defaulting to 300 seconds.
Battery is discharging (10.29% left)
Battery health: 102.60%
Please wait...
Battery discharged 0.74% in 300 second(s).

glevin@ is swamped with other things ATM.  jennyz@ can you dig into this one?

jshin@ - Could I get your opinion on something as I'm trying to figure this one out?

Looking at the code in PowerStatusView::UpdateText() (see comment #13), it seems like the only way this could happen is if TimeDurationFormat() was returning an empty string.  The fact that the UI is saying "left" implies that IDS_ASH_STATUS_TRAY_BATTERY_TIME_LEFT_SHORT is being used; therefore PowerStatus::ShouldDisplayBatteryTime() is returning true, so we know that |time| is between 1m and 24h.  TimeDurationFormat() returning an empty or otherwise unprintable string is the only code path I can see that gives this result.

Now, according to the bug, this problem appeared in M-56, but wasn't in M-55.  And I remembered that M-56 is when we switched to ICU 58, and the code in TimeDurationFormat() relies on ICU code.

I don't know much about the ICU library.  Is there ANY chance that a bug in ICU 58 could be causing the code in TimeDurationFormat() to fail on some but not all devices?  Even if it's unlikely, the above clues seem to point to this idea as at least a possibility.

Thoughts?

re comment#34

Asus Chromebook Flip, Beta Channel, non dev mode

crosh> battery_information
ERROR: unknown command: battery_information

crosh> battery_firmware info
Sorry, but this command is unavailable on this device.

crosh> battery_firmware check
Sorry, but this command is unavailable on this device.

crosh> battery_test
No test length specified. Defaulting to 300 seconds.
Battery is discharging (48.95% left)
Battery health: 90.66%
Please wait...
Battery discharged 0.51% in 300 second(s).
crosh> 

also re comment #34

Toshiba Chromebook 2 (Ver58.0.3021.3dev)
Platform 9313.1.0 (Official Build)dev-channel swanky
FW Google_Swanky.5216.238.5

crosh> battery_firmware info
Sorry, but this command is unavailable on this device.

crosh> battery_firmware check
Sorry, but this command is unavailable on this device.

crosh> battery_test
No test length specified. Defaulting to 300 seconds.
Battery is discharging (22.37% left)
Battery health: 85.33%
Please wait...
Battery discharged 0.86% in 300 second(s).
crosh> 

Thanks, no need for more output from battery_firmware or battery_test.

Proposing the following CL to capture more info (unless someone already has a good lead): https://codereview.chromium.org/2731463002/

Just to add to the list I have a HP Chromebook 14 that is displaying the same problem, eg 44% -  left.

Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

powerd.LATEST does report the correct time left.

I am also experiencing this issue. 

HP 11 G5.
Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel setzer
ARC Version 3756504
Firmware Google_Setzer.7287.298.0

I tried the suggested change earlier in the thread with the ash-md to disabled and this had no effect. Any news on this? Such a handy feature.

I also have the same problem on Acer C720
Version 56.0.2924.110 (64-bit)
Platform 9000.91.0 (Official Build) stable-channel peppy
Firmware Google_Peppy.4389.93.0

I have submitted a log using Alt+Shift+i

Deleted: Screenshot 2017-03-06 at 18.26.25.png 11.2 KB

	Screenshot 2017-03-06 at 18.26.25.png 11.2 KB View Download

I've sent https://codereview.chromium.org/2734883003/ to add some logging when we encounter ICU errors (which I suspect are to blame here). Hopefully it'll be possible to merge it to earlier releases.

Sorry for being late. Thank you, Dan. 

At first, I thought the remaining time was longer than 24 hours and ICU might have a bug for that (as is the case for Width_numeric), but comment 23 does not have such a long duration. 

So, Dan's logging seems to be the best hope to find out. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9

commit efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9
Author: derat <derat@chromium.org>
Date: Tue Mar 07 18:25:44 2017

base: Make TimeDurationFormat* report failures.

Update base::TimeDurationFormat() and
base::TimeDurationFormatWithSeconds() to return boolean
"success" values and use out-params to return formatted
strings. ICU errors were formerly swallowed, which makes it
impossible for the UI to handle them gracefully or for
developers to investigate their causes.

BUG=698802, 677043 

Review-Url: https://codereview.chromium.org/2734883003
Cr-Commit-Position: refs/heads/master@{#455144}

[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/ash/common/system/chromeos/power/battery_notification.cc
[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/ash/common/system/chromeos/power/power_status_view.cc
[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/base/i18n/time_formatting.cc
[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/base/i18n/time_formatting.h
[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/base/i18n/time_formatting_unittest.cc
[modify] https://crrev.com/efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9/chrome/browser/ui/task_manager/task_manager_table_model.cc

Thanks derat@. Can we get logging merged down to 57 or even 56 so users have an easier time reproducing with logs?

The ship has sailed for 56, but yes, merging to 58 and 57 seems reasonable.

Note for TPMs reviewing merge requests: the change from #51 adds some more logging but won't fix the underlying issue.

Also removing ReleaseBlock-Stable because it doesn't make much sense for a bug that's already present on the stable channel.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7

commit eaf9c6686c55d0b2d3cbe2c69818db7f017187e7
Author: Daniel Erat <derat@chromium.org>
Date: Wed Mar 08 23:17:08 2017

base: Make TimeDurationFormat* report failures.

Update base::TimeDurationFormat() and
base::TimeDurationFormatWithSeconds() to return boolean
"success" values and use out-params to return formatted
strings. ICU errors were formerly swallowed, which makes it
impossible for the UI to handle them gracefully or for
developers to investigate their causes.

BUG=698802, 677043 

Review-Url: https://codereview.chromium.org/2734883003
Cr-Commit-Position: refs/heads/master@{#455144}
(cherry picked from commit efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9)

Review-Url: https://codereview.chromium.org/2736363002 .
Cr-Commit-Position: refs/branch-heads/3029@{#73}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/ash/common/system/chromeos/power/battery_notification.cc
[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/ash/common/system/chromeos/power/power_status_view.cc
[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/base/i18n/time_formatting.cc
[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/base/i18n/time_formatting.h
[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/base/i18n/time_formatting_unittest.cc
[modify] https://crrev.com/eaf9c6686c55d0b2d3cbe2c69818db7f017187e7/chrome/browser/ui/task_manager/task_manager_table_model.cc

I'm seeing this right now with a dev-mode Pixel 1, if that's helpful to anyone.

Chrome 59.0.3033 (from Monday March 6), OS 9346 self-built from 3/8

Menu just shows "99%" and no " - left"

Device is on AC power.

Copy/paste isn't working on crosh, so I'll attach a screenshot of the battery info.

Deleted: battery-screenshot.png 473 KB

	battery-screenshot.png 473 KB View Download

Nevermind, I was on AC power. After disconnecting power I get the normal "99% - 4:23 left" message.

Why has the M57 merge review for this not happened yet?

Approving merge to M57 Chrome OS. All fixes have to bake on M58 for at least a day before they are merge approved to M57.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/01ae29ee6c467754119319d62513e97085eafa96

commit 01ae29ee6c467754119319d62513e97085eafa96
Author: Daniel Erat <derat@chromium.org>
Date: Mon Mar 13 23:20:57 2017

base: Make TimeDurationFormat* report failures.

Update base::TimeDurationFormat() and
base::TimeDurationFormatWithSeconds() to return boolean
"success" values and use out-params to return formatted
strings. ICU errors were formerly swallowed, which makes it
impossible for the UI to handle them gracefully or for
developers to investigate their causes.

BUG=698802, 677043 
TBR=jshin@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2734883003
Cr-Commit-Position: refs/heads/master@{#455144}
(cherry picked from commit efcd30ca164e0e1bbcfe402840d8c23aa9d40fd9)

Review-Url: https://codereview.chromium.org/2745233002 .
Cr-Commit-Position: refs/branch-heads/2987@{#818}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/ash/common/system/chromeos/power/battery_notification.cc
[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/ash/common/system/chromeos/power/power_status_view.cc
[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/base/i18n/time_formatting.cc
[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/base/i18n/time_formatting.h
[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/base/i18n/time_formatting_unittest.cc
[modify] https://crrev.com/01ae29ee6c467754119319d62513e97085eafa96/chrome/browser/ui/task_manager/task_manager_table_model.cc

 Issue 696968  has been merged into this issue.

Reproduced issue on Kevin 9334.13.0 / 58.0.3029.19

Feedback report here: http://feedback/#/Report/55228755132

Device logs here: https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/677043/

Thanks. It's an error from ICU!

[1526:1526:0317/171128.146500:ERROR:time_formatting.cc(203)] Creating MeasureFormat for en_GB failed: U_RESOURCE_TYPE_MISMATCH
[1526:1526:0317/171128.146728:ERROR:power_status_view.cc(130)] Failed to format duration 3451000000
[1526:1526:0317/171128.157713:ERROR:time_formatting.cc(203)] Creating MeasureFormat for en_GB failed: U_RESOURCE_TYPE_MISMATCH
[1526:1526:0317/171128.157885:ERROR:power_status_view.cc(130)] Failed to format duration 3451000000

And sigh, this problem is trivially easy to reproduce by setting the locale to en_GB.

Here's the call that's failing:

201   icu::MeasureFormat measure_format(icu::Locale::getDefault(), u_width, status);
202   if (U_FAILURE(status)) {
203     LOG(ERROR) << "Creating MeasureFormat for "
204                << icu::Locale::getDefault().getName()
205                << " failed: " << u_errorName(status);
206     return false;
207   }

u_width comes from here:

 75 UMeasureFormatWidth DurationWidthToMeasureWidth(DurationFormatWidth width) {
 76   switch (width) {
 77     case DURATION_WIDTH_WIDE: return UMEASFMT_WIDTH_WIDE;
 78     case DURATION_WIDTH_SHORT: return UMEASFMT_WIDTH_SHORT;
 79     case DURATION_WIDTH_NARROW: return UMEASFMT_WIDTH_NARROW;
 80     case DURATION_WIDTH_NUMERIC: return UMEASFMT_WIDTH_NUMERIC;
 81   }
 82   NOTREACHED();
 83   return UMEASFMT_WIDTH_COUNT;
 84 }

We're calling this with DURATION_WIDTH_NUMERIC. I'll check if using DURATION_WIDTH_NARROW yields different results for en_GB. If so, maybe we need to fall back (although the ICU docs seem unclear here). :-/

Jungshik, are you the right person to look at this? Will you be able to sometime soon? It looks like an ICU problem.

Confirmed it also repros in es-419 (Spanish - Latin America).

Battery life appears correctly for me in chrome://md-settings, but not in the status menu.

Version 57.0.2987.123 (64-bit)
Platform 9202.56.1 (Official Build) stable-channel lars
ARC Version 3831942
Firmware Google_Lars.7820.127.0

Deleted: Screenshot 2017-03-25 at 08.53.45.png 9.9 KB

	Screenshot 2017-03-25 at 08.53.45.png 9.9 KB View Download

Deleted: Screenshot 2017-03-25 at 08.53.30.png 15.9 KB

	Screenshot 2017-03-25 at 08.53.30.png 15.9 KB View Download

I checked mine with chrome://md-settings and found I cant see battery underneath Storage Management. Weird.

Users reporting it still does not work on V57, falco and edgar
CBC topic https://goo.gl/CuWAmE

Version 57.0.2987.123 (64-bit)
Platform 9202.56.1 (Official Build) stable-channel falco
Firmware Google_Falco.4389.92.0

Version 57.0.2987.123 (64-bit)
Platform 9202.56.1 (Official Build) stable-channel edgar
Firmware Google_Edgar.7287.167.42

Thanks, but it still hasn't been fixed -- no need for further reports.

Jungshik, if you don't have time to figure out why ICU is returning an error, can you suggest someone else who can?

Sorry to bump. I have starred this, but wanted to contribute my version and build information.

Version 57.0.2987.137 (64-bit)
Platform 9202.60.0 (Official Build) stable-channel quawks
Firmware Google_Quawks.5216.204.61

Device: Asus C300M

The battery icon also not appearing under 'chrome://md-settings > Device' list (see attachment). 

Deleted: Screenshot 2017-04-01 at 11.24.52.png 7.2 KB

	Screenshot 2017-04-01 at 11.24.52.png 7.2 KB View Download

Deleted: Screenshot 2017-04-01 at 11.24.42.png 1.9 KB

	Screenshot 2017-04-01 at 11.24.42.png 1.9 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/deps/icu.git/+/d5c238dcc2e801210749f3bb421b9227fe1c0948

commit d5c238dcc2e801210749f3bb421b9227fe1c0948
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Apr 11 21:58:59 2017

Update trim_data to deal with locale fallback failure for units

Delete empty units,units{Narrow,Short} blocks after trimming units data.
Empty units* blocks in en_GB and a few other locales after trimming
causes ICU to fail to fall back to get the duration data for those
locales.

In addition, fix source/data/translit/root_subset.txt. Rule*Ids block has
to be present even though it's empty. When dropping Hans-Hant transform
rules, root_subset.txt was changed to be completely empty, which broke
"components_unittests --g_test_filter=AutofillProfileComparato*" .

With these changes, regenerate ICU data files. The size is slightly smaller.

android/icudtl.dat  6573872 => 6573792
common/icudt*dat    10130560 => 10130480

BUG= 707515 , 677043 , 684609 
TEST=components_unittests --gtest_filter=AutofillProfileComparato*
TEST=ui_base_unittests --gtest_filter=L10nUtilTest.TimeDurationForm*
R=derat@chromium.org

Review-Url: https://codereview.chromium.org/2812943003 .

[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/android/icudtl.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/common/icudtb.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/common/icudtl.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/scripts/trim_data.sh
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/source/data/translit/root_subset.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/deps/icu.git/+/d5c238dcc2e801210749f3bb421b9227fe1c0948

commit d5c238dcc2e801210749f3bb421b9227fe1c0948
Author: Jungshik Shin <jshin@chromium.org>
Date: Tue Apr 11 21:58:59 2017

Update trim_data to deal with locale fallback failure for units

Delete empty units,units{Narrow,Short} blocks after trimming units data.
Empty units* blocks in en_GB and a few other locales after trimming
causes ICU to fail to fall back to get the duration data for those
locales.

In addition, fix source/data/translit/root_subset.txt. Rule*Ids block has
to be present even though it's empty. When dropping Hans-Hant transform
rules, root_subset.txt was changed to be completely empty, which broke
"components_unittests --g_test_filter=AutofillProfileComparato*" .

With these changes, regenerate ICU data files. The size is slightly smaller.

android/icudtl.dat  6573872 => 6573792
common/icudt*dat    10130560 => 10130480

BUG= 707515 , 677043 , 684609 
TEST=components_unittests --gtest_filter=AutofillProfileComparato*
TEST=ui_base_unittests --gtest_filter=L10nUtilTest.TimeDurationForm*
R=derat@chromium.org

Review-Url: https://codereview.chromium.org/2812943003 .

[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/android/icudtl.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/common/icudtb.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/common/icudtl.dat
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/scripts/trim_data.sh
[modify] https://crrev.com/d5c238dcc2e801210749f3bb421b9227fe1c0948/source/data/translit/root_subset.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a8550bc1391772685da6e86adc72a587bd964289

commit a8550bc1391772685da6e86adc72a587bd964289
Author: derat <derat@chromium.org>
Date: Tue Apr 11 22:11:31 2017

Add test for TimeDurationFormat() error.

base::TimeDurationFormat() fails due to a
U_RESOURCE_TYPE_MISMATCH error from ICU when called with
certain locals like en_GB due to missing resource data.
Add a test (disabled for now) to verify that it works
for all supported locales.

BUG= 677043 , 707515 

Review-Url: https://codereview.chromium.org/2793613004
Cr-Commit-Position: refs/heads/master@{#463796}

[modify] https://crrev.com/a8550bc1391772685da6e86adc72a587bd964289/ui/base/l10n/l10n_util_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf65b91bc7496b3dd2c958c890984e73c26ad22c

commit cf65b91bc7496b3dd2c958c890984e73c26ad22c
Author: jshin <jshin@chromium.org>
Date: Wed Apr 12 00:34:12 2017

Roll third_party/icu from 450be73 to b34251f

http://chromium.googlesource.com/chromium/deps/icu.git/+log/450be73..b34251f

Changes include (along with minor data build script updates):

  1. f0449ad Update IANA timezone db to 2017a from 2016i
  2. c781b5f Drops unused Hans-Hant ICU transliteration data.
     ( cuts down the ICU data file size by ~25kB.)
  3. d5c238d Update trim_data to deal with locale fallback failure for units
     and fix root_subset.txt in ICU's transliteration configuration.
  4. b34251f Update timezone db to 2017b

BUG= 684609 ,473288, 707515 , 677043 
TEST=components_unittests --gtest_filter=AutofillProfileComparato*
TEST=ui_base_unittests --gtest_filter=L10nUtilTest.TimeDurationForm*
TEST=For timezone change test, see CL #1 and #4 TEST lines.
TBR=riesa@chromium.org,derat@chromium.org

Review-Url: https://codereview.chromium.org/2755963002
Cr-Commit-Position: refs/heads/master@{#463856}

[modify] https://crrev.com/cf65b91bc7496b3dd2c958c890984e73c26ad22c/DEPS
[modify] https://crrev.com/cf65b91bc7496b3dd2c958c890984e73c26ad22c/ui/base/l10n/l10n_util_unittest.cc

This should be fixed in canary. 

Will bake a day or two there before asking for merge. 

It should be verified with the UI language set to en-GB (British English) or es-419 (Latin American Spanish). 

I'll file a bug against monorail to revise a bug template to include OS UI language and Chrome UI language (automatically if possible. at least ask a reporter to fill out the value if not). 

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/buildspec/+/cd0a1e71a466bf114861203e987fb7ed07e5efd6

commit cd0a1e71a466bf114861203e987fb7ed07e5efd6
Author: Jungshik Shin <jungshik@google.com>
Date: Thu Apr 20 19:47:02 2017

Verified on 
Chrome OS 9460.5.0/59.0.3071.15  Kevin
Chrome OS 9334.52.0/58.0.3029.78 Chell

With UI language set to en-GB (British English) or es-419 (Latin American Spanish)

> I'll file a bug against monorail to revise a bug template to include OS UI language and Chrome UI language (automatically if possible. at least ask a reporter to fill out the value if not). 

Filed bug monorail:2594