As explained in bug 1314354, comment #10. This depends on bug 1328386.

Comment on attachment 8827422 [details] [diff] [review] bug1331474.patch Review of attachment 8827422 [details] [diff] [review]: ----------------------------------------------------------------- Ugh. Why don't we try getting the spec changed to make these plain objects, rather than deferring logic and violating the spec?

Incidentally, just hacking LoginMumble.jsm is more and more looking like probably the fastest bandaid, and we can do the spec stuff with somewhat more leisure than trying to just shoehorn in something without experience in the field to say it's good.

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #2) > Ugh. Why don't we try getting the spec changed to make these plain objects, > rather than deferring logic and violating the spec? As mentioned in the other bug, we may already violate the Intl spec due the lazy initialization of the Intl object itself. The main spec doesn't even specify whether or not LocalTZA can change at runtime [1]. :-/ [1] https://tc39.github.io/ecma262/#sec-local-time-zone-adjustment Later: I was worried user code might call "Intl.DateTimeFormat.prototype.resolvedOptions()" to get the default options (same for Intl.NumberFormat.prototype and Intl.Collator.prototype), which could result in web-compat issues when we try to change the Intl prototype objects to be no longer Intl object instances. But then I found out that Chrome/V8 already treats the prototype objects as plain objects instead of Intl object instances. So changing the spec seems to be feasible! \o/

Filed bug 1332604 for the Intl prototype change.

Superseded by bug 1332604.