When experimenting with outgoing EWS configurations for Thunderbird's upcoming Exchange implementation, I noticed that the display name for an outgoing Microsoft 365 server (which is discovered via ISPDB, following an MX record lookup) would turn up as "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)", which I found weird. When digging a bit further, I stumbled upon our [JXON](https://searchfox.org/comm-central/source/mailnews/base/src/JXON.sys.mjs) implementation, which role is to turn an `XMLDocument` into a more JS-like object structure, i.e. one where a child element can be accessed with `parent.child` rather than `parent.getElementsByTagName("child")[0]`. This implementation comes from bug 759422, which copies it from https://web.archive.org/web/20121105150802/https://developer.mozilla.org/en-US/docs/JXON with a few modifications. When parsing text ([here](https://searchfox.org/comm-central/rev/7cefa1199be9cf0a9ce788f4cc73e38002eb8411/mailnews/base/src/JXON.sys.mjs#16-27)), because JXON doesn't know what kind of data is in the text of an XML node, it tries to be helpful and parse this text as different types via trial an error, before deciding it can't do anything more with it and returning it as plain text. One of these checks is whether `Date.parse(text)` returns a finite number. If so, it returns a new `Date` object from the text. It turns out that for some reason, `Date.parse("Microsoft 365")` does return a finite number. And the string representation of a `Date` object created from the string "Microsoft 365" is "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)". When looking at the comm-central repository, it appears we only use JXON (or its main consumer, `FetchHTTP`) in two contexts, both in the account setup code: * when parsing an autoconfig file, or * when parsing an Exchange autodiscover response The [autoconfig file format](https://www.bucksch.org/1/projects/thunderbird/autoconfiguration/config-file-format.html) does not specify any element containing a date, and the [method](https://searchfox.org/comm-central/rev/978bf6b1cdd7330e7cfb8626949c02a777532e9f/mail/components/accountcreation/modules/ExchangeAutoDiscover.sys.mjs#371) used to process an Exchange autodiscover response does not seem to access any element that is expected to contain a date. Therefore, and considering the discussion in bug 759422 (which leads me to think we do this only because the place we copied it from does), I propose removing this check/conversion to `Date` from the JXON implementation. Ideally I think we should remove these conversion attempts altogether and let the consumer (which is the code that is supposed to know how to interpret each element's content) in charge of converting a value to the correct type, but I can settle with considering this as a future step.
Bug 1902742 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
When experimenting with outgoing EWS configurations for Thunderbird's upcoming Exchange implementation, I noticed that the display name for an outgoing Microsoft 365 server (which is discovered via ISPDB, following an MX record lookup) would turn up as "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)", which I found weird. When digging a bit further, I stumbled upon our [JXON](https://searchfox.org/comm-central/source/mailnews/base/src/JXON.sys.mjs) implementation, which role is to turn an `XMLDocument` into a more JS-like object structure, i.e. one where a child element can be accessed with `parent.child` rather than `parent.getElementsByTagName("child")[0]`. This implementation comes from bug 759422, which copies it from https://web.archive.org/web/20121105150802/https://developer.mozilla.org/en-US/docs/JXON with a few modifications. When parsing text ([here](https://searchfox.org/comm-central/rev/7cefa1199be9cf0a9ce788f4cc73e38002eb8411/mailnews/base/src/JXON.sys.mjs#16-27)), because JXON doesn't know what kind of data is in the text of an XML node, it tries to be helpful and parse this text as different types via trial an error, before deciding it can't do anything more with it and returning it as plain text. One of these checks is whether `Date.parse(text)` returns a finite number. If so, it returns a new `Date` object from the text. It turns out that for some reason, `Date.parse("Microsoft 365")` does return a finite number. And the string representation of a `Date` object created from the string "Microsoft 365" is "Fri Jan 01 0365 00:00:00 GMT-0001 (Greenwich Mean Time)". When looking at the comm-central repository, it appears we nowadays only use JXON (or its main consumer, `FetchHTTP`) in two contexts, both in the account setup code: * when parsing an autoconfig file, or * when parsing an Exchange autodiscover response The [autoconfig file format](https://www.bucksch.org/1/projects/thunderbird/autoconfiguration/config-file-format.html) does not specify any element containing a date, and the [method](https://searchfox.org/comm-central/rev/978bf6b1cdd7330e7cfb8626949c02a777532e9f/mail/components/accountcreation/modules/ExchangeAutoDiscover.sys.mjs#371) used to process an Exchange autodiscover response does not seem to access any element that is expected to contain a date. Therefore, and considering the discussion in bug 759422 (which leads me to think we do this only because the place we copied it from does), I propose removing this check/conversion to `Date` from the JXON implementation. Ideally I think we should remove these conversion attempts altogether and let the consumer (which is the code that is supposed to know how to interpret each element's content) in charge of converting a value to the correct type, but I can settle with considering this as a future step.