Adding RB label as this is a recent regression.

Not sure who caused this issue, but I'm certain that it's not me. My change had to do with a Javascript change to about:tracing

Able to reproduce the issue on Windows 7 using chrome latest canary M53-53.0.2768.0. Observed the clock app is not able to launch it on chrome. 

lpanse@ - Since the assigned Dev confirmed it's not his change, Could you please rebisect this issue and assign it to the concerned Dev person.

With response to comment #3:
Re-bisected on other machine, getting same bisect range
https://chromium.googlesource.com/chromium/src/+log/6868e2b9440a4d4000b8bfa7e8399ac340c35891..495f126aa1c0f77e8b5a99fc0ea741501404ae7a?pretty=fuller&n=50

Suspecting: r395244 ?

Please help to re-assign if your change is not the cause of this issue.

@grt: Could you please look into this issue.

Thank you.

Still able to reproduce the issue on Windows 7, Mac 10.11.5, Ubuntu 14.04 using 53.0.2780.0.

@grt: Could you please look into this issue.

Still able to repro this issue on Canary Version - 53.0.2784.1

Just to update, this issue is still observed on canary 54.0.2794.0 on Windows 7, MAC 10.11.5, Ubuntu 14.04. Request someone to please take a look into it.

Thanks.!

Looks to me like the app is throwing an exception:

"Uncaught TypeError: Cannot read property 'pattern' of undefined", source: chrome-extension://galgfocamdohgeifjlbefkfpaalankfi/background.js (7)

The problem is here:

  var dateFormat = new Intl.DateTimeFormat(undefined, { hour: 'numeric' });
  var pattern = dateFormat.resolved.pattern;

dateFormat.resolved is undefined, hence the error.

If this same app used to work, then something has changed in Chrome. Either the error didn't prevent the app from loading, or our DateTimeFormat used to have a "resolved" property. I don't have knowledge of either of these, so I'll step back and let someone else pick this up.

Could someone please take an ownership for this issue, as it is marked with a Stable blocker and M53 is set to pushed to Beta Soon. Issue still persists on Dev #53.0.2785.8

Adding Needs-Triage label.

Thanks.!

ulan: Chrome 51 and 53 handle DateTimeFormat differently. Specifically, DateTimeFormat instances no longer have a "resolved" member. Could this be a result of your change at https://chromium.googlesource.com/v8/v8/+/1f6be3d73ce74460bed4c7a8b4ebec79e446fbe0? If no, could you help us find out what changed? Thanks for your help.

Found this by googling "chromium dateformat resolved" :)
https://bugs.chromium.org/p/v8/issues/detail?id=3785

There CL at the end:
https://codereview.chromium.org/1968893002

This patch removes the following properties, as their use count is
very low, they are V8-only, and not on a standards track.
- v8Parse
- resolved
- pattern

So looks like this is working as intended.

Deferring to Dan to confirm.

The Google is strong with this one. :-) Thanks, ulan!

Can someone reach out to the developer of this app and tell them to update it?

Yes, these were purposely removed due to their low usage count and lack of standardization. In particular, Microsoft had objected to "pattern" as being too ICU/CLDR-specific in the past, and so it was purposely left out of the specification. Unfortunately, there is no replacement at the moment to get at that sort of internationalization data besides just formatting a time and then trying to parse it and see what you can get out of it (which I've heard some JS internationalization libraries in fact do). I'll contact the developer and report the issue.

I filed a bug and explained how to fix at https://github.com/kaydensigh/chromecalclock/issues/9

The author applied a fix at https://github.com/kaydensigh/chromecalclock/commit/5276fdf751cb7dec47669fe3ddc2c58ddbf70a36 .