2007641 - www.papajohns.com - Error displayed when trying to checkout

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Linux/Windows 10
Firefox version: Firefox 145.0/146/148

Steps to reproduce:

1. Go to https://www.papajohns.com/omni/en/order/carryout
2. Enter a zip code (e.g. 73301)
3. Continue and select a store.
4. Add a product to the cart.
5. Access the cart and click on "Check out".

Expected Behavior:
The checkout page is displayed.

Actual Behavior:
It shows an error "OH NO! Looks like we left this page in the oven too long.".

Notes:

• Chrome Mask doesn't seem to help
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/196731

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[Alice0775 White]

Console error:

RangeError: Invalid time value
    NextJS 22
    g https://www.papajohns.com/assets/054ce4aef57aa23a07c65a17f86637b02598cfb325b:37
    apply https://www.papajohns.com/assets/054ce4aef57aa23a07c65a17f86637b02598cfb325b:38
    NextJS 6
    around https://cdn.appdynamics.com/adrum/adrum-24.4.0.4454.js:48
    g https://www.papajohns.com/assets/054ce4aef57aa23a07c65a17f86637b02598cfb325b:37
    Yj https://cdn.appdynamics.com/adrum/adrum-24.4.0.4454.js:18
    n https://cdn.appdynamics.com/adrum/adrum-24.4.0.4454.js:193
    apply https://www.papajohns.com/assets/054ce4aef57aa23a07c65a17f86637b02598cfb325b:40
    around https://cdn.appdynamics.com/adrum/adrum-24.4.0.4454.js:48
    NextJS 25
critical-42400a5a01dad6ce.js:1:244453

Comment 3

[Jeff Muizelaar [:jrmuizel]]

new Intl.DateTimeFormat(void 0, {timeZone: "CST"})

is throwing in Firefox but not in Chrome or Safari

Comment 4

[Jeff Muizelaar [:jrmuizel]]

CST is in this list of legacy timezones that we drop: https://searchfox.org/firefox-main/rev/e7efe8e2d1b972ed4a073065bc99cfb08f6c31e9/js/src/builtin/intl/TimeZoneDataGenerated.h#92

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Randell found that these names are actually ambiguous? https://data.iana.org/time-zones/tzdb-2022b/theory.html

But anyhow... Andre, Jonathan, do you know why we drop them / should we avoid dropping them for compat, or try to push other browsers to do the same instead?

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Note about the STR. It's important to choose a zipcode in an unsupported timezone like CST.

Comment 7

[André Bargull [:anba]]

CST isn't a valid IANA time zone identifier, therefore it's rejected in SpiderMonkey to match the ECMA-402 specification. V8 doesn't perform any IANA time zone validity checks and simply defers to ICU4C, but because ICU4C supports IANA time zone identifiers and non-standard ICU4C time zone names, like for example CST, some non-valid IANA time zones are incorrectly accepted by V8.

JSC was fixed in November to reject ICU4C time zone identifiers, most likely this change hasn't yet landed in the release version of Safari.

• Full list of non-standard ICU4C specific time zone identifiers: https://searchfox.org/firefox-main/source/intl/icu/source/tools/tzcode/icuzones.
• ECMA-402 spec: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
• Test262: https://github.com/tc39/test262/blob/main/test/intl402/DateTimeFormat/timezone-legacy-non-iana.js
• JSC bug: https://bugs.webkit.org/show_bug.cgi?id=296248

Comment 8

[Jonathan Kew [:jfkthame]]

While it looks like our behavior here is correct, as André explains in comment 7, I wonder if we should nevertheless look into possible workarounds given the user-facing breakage. (Unless of course we can persuade the site to deploy a fix promptly.)

How does the zip code get mapped to a timezone? I'm guessing this is done by some JS on the page (I can't readily check as papajohns.com just redirects to their UK site for me); if we can't get them to fix the site, maybe we can intercept and patch this?

FWIW, even Safari Tech Preview still accepts "CST" for me, though I may not have the most up-to-date version (running on Sonoma here).

Comment 9

[Jeff Muizelaar [:jrmuizel]]

I believe CST is coming from JSON from the server. The easiest way to patch this is probably to override new Intl.DateTimeFormat(void 0, {timeZone: "CST"}) and make it swap CST for the proper timezone.

André, can you file a bug against V8/blink?

Comment 10

[André Bargull [:anba]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)

André, can you file a bug against V8/blink?

Filed as https://issues.chromium.org/issues/475214795.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I need to use https://www.papajohns.com/order/carryout?target=&isEdit= to reproduce instead of the original https://www.papajohns.com/omni/en/order/carryout

Comment 12

[Thomas Wisniewski [:twisniewski]]

Chrome accepts AST, EST, CST, HST, MST, PST, and SST in my testing (Firefox does not). I'll make an intervention which overrides those values to appropritate values, just in case Papa John's also use them in some cases.

Comment 13

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 2007641 - add a JS webcompat intervention for Papa John's to work around non-standard values being passed into Intl.DateTimeFormat timeZones; r?denschub

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c592f41c98e7
https://hg.mozilla.org/integration/autoland/rev/b06c8d93a22e
add a JS webcompat intervention for Papa John's to work around non-standard values being passed into Intl.DateTimeFormat timeZones; r=webcompat-reviewers,ksenia

Comment 15

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/b06c8d93a22e