Vangelis66
commented
1 year ago I can't say whether this is just a bug in GitHub's untested fallback when the browser doesn't have
Intl.RelativeTimeFormat, or something weirder. ... If the same issue is affecting PM
Well, I can't test latest official Pale Moon (v31.3.1) in my current OS but, by the looks of it, it, too, should at least exhibit #60; NB that this browser does carry native IRTF support, so, to use your wording 😉 , "something weirder" is taking place here...
martok
dirkf
Lots of GitHub functionality is broken now in SeaMonkey 2.53.14 by this:
From my analysis below I can't say whether this is just a bug in GitHub's untested fallback when the browser doesn't have
Intl.RelativeTimeFormat, or something weirder. For the moment I am polyfillingIntl.RelativeTimeFormatusing a NoScript surrogate for<.githubassets.comto fix the issue, which favours the former explanation. If the same issue is affecting PM and it can be fixed in PF instead that would be great.Analysis
The problem code comes from https://github.com/github/relative-time-element. The original code is TypeScript but the bundled code sent by GH is minimised JS with JS source mapping. According to the SM debugger, the failing line is the apparently unproblematic ```js const relativeFormat = new RelativeTimeFormat(locale, { numeric: 'auto' }); ``` In the minimised JS, this is indeed `l = new v(k, {numeric: "auto"});`. The class `RelativeTimeFormat` is either `window.Intl.RelativeTimeFormat` (not defined in SM 2.53.14), or a "ponyfill": ```js ..., u = "Intl" in window && "RelativeTimeFormat", v = u ? Intl.RelativeTimeFormat : class RelativeTimeFormat { formatToParts() {...} resolvedOptions() {...} format(a, b) {...} }; ... ``` Although `u` must be `false`, somehow the ponyfill is being discarded. As I understand, since the ponyfill class has no constructor, the `new` args should just be discarded, rather than throwing an exception, like this Scratchpad output: ``` var v = class foo {}; new v(1,2,3); /* [object Object] */ ``` The ponyfill code: https://github.com/github/relative-time-element/raw/main/src/relative-time-ponyfill.ts The NoScript replacement using the rendering of that in the SM debugger: ```js if 'Intl' in window && !Intl.RelativeTimeFormat { class xRelativeTimeFormat { formatToParts() { return []; } resolvedOptions() { return { locale: 'en', style: 'long', numeric: 'auto', numberingSystem: 'nu' }; } format(value, unit) { if (value === 0) { switch (unit) { case 'year': case 'quarter': case 'month': case 'week': return `this ${unit}`; case 'day': return 'today'; case 'hour': case 'minute': return `in 0 ${unit}s`; case 'second': return 'now'; } } else if (value === 1) { switch (unit) { case 'year': case 'quarter': case 'month': case 'week': return `next ${unit}`; case 'day': return 'tomorrow'; case 'hour': case 'minute': case 'second': return `in 1 ${unit}`; } } else if (value === -1) { switch (unit) { case 'year': case 'quarter': case 'month': case 'week': return `last ${unit}`; case 'day': return 'yesterday'; case 'hour': case 'minute': case 'second': return `1 ${unit} ago`; } } else if (value > 1) { switch (unit) { case 'year': case 'quarter': case 'month': case 'week': case 'day': case 'hour': case 'minute': case 'second': return `in ${value} ${unit}s`; } } else if (value < -1) { switch (unit) { case 'year': case 'quarter': case 'month': case 'week': case 'day': case 'hour': case 'minute': case 'second': return `${-value} ${unit}s ago`; } } throw new RangeError(`Invalid unit argument for format() '${unit}'`); } } window.Intl.RelativeTimeFormat = xRelativeTimeFormat } ``` Personally I strongly disfavour anything that mucks around with date-time displays, especially if it's going to be continually updating all the date-time displays in all the open pages. They should use ISO 8601 date-time and put this "25 minutes ago" stuff in a tooltip that gets calculated when the tooltip is displayed.