legacy.com Page navigation broken in version 34 Topic is solved

[q160765803]

Page navigation of https://www.legacy.com/us/obituaries/wa ... ost/browse is broken in new version 34.0, while it works in 33.9.1.

Please try to include any relevant output from the Toolkit Error Console or the Developer Tools Web Console using the following procedure:

1) Clear any current output
2) Navigate or refresh the page in question
3) Copy and paste Errors or seemingly relevant Warnings into a single [ code ] block.

The Dates in javascript request becomes "Invalid Date" in version 34:

Code: Select all

GET /api/_frontend/obituaries?endDate=Invalid%20Date&limit=50&noticeType=all&offset=50&sortBy=date&startDate=Invalid%20Date&affiliateSiteName=washingtonpost HTTP/1.1
Host: www.legacy.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:128.0) Gecko/20100101 Goanna/6.8 Firefox/128.0 PaleMoon/34.0.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-User-Agent: 
Referer: https://www.legacy.com/us/obituaries/washingtonpost/browse
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

[Moonchild]

I don't see any problem with the URL given. Dates display correctly.

[q160765803]

I don't see any problem with the URL given. Dates display correctly.

If you press Page Number in bottom of page to jump to different page, it uses javascript to fetch content of different page number.
And in version 34, the endDate of that XHR request becomes "Invalid Date"

[Moonchild]

Aha.

Code: Select all

"'endDate' must be either YYYY-MM-DD or MM-DD-YYYY"
"'startDate' must be either YYYY-MM-DD or MM-DD-YYYY"

I guess there's some subtleties going on here with the ICU update.

[THX-1139]

Working fine for me; It worked in the previous release of PM and then I just now updated to the newest version (34) and it still works, even after selecting many different page numbers...

[THX-1139]

And after further browsing through too many Obit's I thought: Why does it use Washington Post Obit's but not the WP url?

[RealityRipple]

Been trying to narrow this down, but I don't actually have a debug environment set up, just compilation; so without narrowing down what date-related function is being called with what parameters, I'm not sure where the discrepancy lies. That being said, there are a handful of bz bugs (such as these) about parsing various formats, dates, and timezone representations, and unfortunately, they're not organized very well, so "settling the dust" on the ICU update might take some time, as will implementing the new Intl functions.

[adoxa]

The date string contains NARROW NO-BREAK SPACE (U+202F), which causes new Date to fail. Here's a Modify HTTP Response filter to replace it.

Code: Select all

[["www.legacy.com",["/\\d.*\\.js$/",["new Date(t)}","new Date(t.replace(\"\\u202f\",\" \"))}"]]]]

[Moonchild]

The date string contains NARROW NO-BREAK SPACE (U+202F)

OK seems the problem is that ICU 72 actually does this.

See also: https://github.com/date-fns/date-fns/issues/3348

In JavaScript engines that implement unicode ICU 72, Date's toLocaleString function returns a "NARROW NO-BREAK SPACE" (U+202F) unicode character before 'AM/PM'.
Maybe also in other cases, but that's the one where I noticed it.
This leads to an error when used in date-fns parse function.
To reproduce:

Go somewhere where date-fns is available in the console, such as https://date-fns.org/v2.29.3/docs/parse
Run init() in the console and wait for confirmation
Run the following code

const date = new Date()
const localeStr = date.toLocaleTimeString('en-US', {
hour12: true,
hour: 'numeric',
minute: '2-digit'
})
_.parse(localeStr, 'h:mm a', new Date())

You will get Invalid Date.
But if you remove the space or enter a regular space, it's fine.
Related:

NodeJS change: nodejs/node#45068
Kind of related issue in the v8 chromium engine: https://bugs.chromium.org/p/v8/issues/detail?id=13490
"Normalization of spaces" issue: https://unicode-org.atlassian.net/browse/CLDR-14032

[jobbautista9]

Mozilla had this issue too it seems in bug #1806042. The testcase shows the result variable being null in v34, while in a portable of v33.9 and every other current version of a mainstream browser it is not null.

[q160765803]

Mozilla had this issue too it seems in bug #1806042. The testcase shows the result variable being null in v34, while in a portable of v33.9 and every other current version of a mainstream browser it is not null.

wow. It looks like replacing special spaces needs to be done before feeding to ICU and after ICU returning a string.

[RealityRipple]

Okay, why the hell is everything to do with ICU in bugzilla under JavaScript: Internationalization API, but then this is under Core: Internationalization?

I'll get a PR for this and then start crawling through that category for additional regressions and pick-ups.

Edit: PR 2921 should resolve this.

[Moonchild]

I'll ... start crawling through that category for additional regressions and pick-ups.

I've created Issue #2923 (UXP) for tracking when you do, to keep things organized without too much overhead.