2033757 - tienda.exito.com - Stuck loading when trying to log in

Status: NEW

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

Description

[Calin Tanase]

Attachment: image.png

Environment:
Operating system: Windows 10
Firefox version: Firefox 149.0.2 (release)/152

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://tienda.exito.com/authentication?returnUrl=/_v/private/host-picker/www.exito.com?currentPage=/
2. Enter an email that you can access and continue.
3. Enter the code received on your email and continue.

Expected Behavior:
Logs in.

Actual Behavior:
Its stuck loading, page slows down the browser.

Notes:

• Doesn't seem to reproduce when recording a performance profile
• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:aa869fe8-22fa-4dcc-b4e9-21307eabb309

Comment 1

[Ksenia Berezina [:ksenia]]

This seems to have worked for me during triage, so setting affect-users:some

Comment 2

[AutoWebCompat]

Attachment: Reproduction script generated by autowebcompat bot

Submitting the emailed access code on the tienda.exito.com passwordless login never completes in Firefox: the page stays on the authentication URL, the content process pegs a CPU core and its memory grows into the gigabytes, leaving the tab frozen and unresponsive. Chrome accepts the same code and redirects to https://www.exito.com/ in about two seconds.

Comment 3

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Infinite webpack chunk-load retry loop caused by a Firefox/Chrome difference in WHEN a document's in-flight subresource loads are aborted relative to a cross-document navigation.

After "Confirmar": accesskey/validate returns 200, PATCH /api/sessions returns 200, and the login app reloads /authentication. In that fresh document the VTEX render-runtime (React plus webpack code splitting) is still lazily fetching route chunks; the outstanding one in every reproduction was https://exitocol.vtexassets.com/_v/public/assets/v1/published/vtex.store-drawer@0.18.1/public/react/0.min.js . Before that chunk finishes loading, the app starts the top-level navigation to the returnUrl (/_v/private/host-picker/www.exito.com..., which redirects to https://www.exito.com/).

Firefox aborts the outgoing document's in-flight loads the instant the navigation STARTS (nsDocShell stop-loading, "abort a document and its descendants") and reports that cancellation to content as an error event on the script element. Chrome leaves in-flight subresource loads running until the new document actually commits.

So in Firefox webpack's jsonp loader rejects with "Loading chunk 0 failed". The render-runtime keeps that rejected chunk promise, so every subsequent render throws the same error, React re-renders and retries, and it never converges (React error #185, Maximum update depth exceeded). No further network request is made for the chunk; the rejection is replayed from memory. The retry loop remounts the whole component tree, and react-side-effect (used by react-helmet, bundled into vtex.render-runtime common.min.js) pushes the instance onto a module-level array in componentWillMount and runs reducePropsToState over that whole array on every mount and unmount. Mounts outnumber unmounts, so the array grows without bound and the reduce becomes O(n^2): that is what pegs a CPU core and grows RSS into the gigabytes. Because tienda.exito.com and www.exito.com are the same site, the pending navigation must commit in the SAME content process, whose main thread is now permanently busy, so the fetched https://www.exito.com/ document can never commit and the tab stays on /authentication, frozen.

This is an engine-behaviour difference, not UA sniffing: identical bundles are served to both browsers. It is a race (the chunk must still be in flight when the navigation starts), which matches the report's "only some users" and "does not reproduce while profiling"; clean Firefox runs reproduced roughly two thirds of the time.

Spec context: HTML's navigate algorithm runs "stop loading" on the navigable (https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate), while aborting a document's ongoing fetches is tied to unloading it (https://html.spec.whatwg.org/multipage/document-lifecycle.html#unloading-documents). The two engines disagree about which applies in the window between "navigation started" and "new document committed".

Evidence:

Real site, headless Firefox 154.0.1 vs Chrome 141.

1. reproduction.mjs in Firefox: 0/3 runs worked (finalUrl stuck at tienda.exito.com/authentication, responsive=false); Chrome reaches https://www.exito.com/ in seconds. Manually driven Firefox reproduced on 3 of 5 attempts. ps on the wedged content process: 47 to 86 percent of a core, RSS 0.5 GB to 1.8 GB within 40 s and 6.9 GB after an hour; parent process also about 35 percent CPU.

2. Firefox console, read from the parent while the tab was wedged: over 1000 identical errors 10-20 ms apart, "Error: Loading chunk 0 failed. (error: https://exitocol.vtexassets.com/_v/public/assets/v1/published/vtex.store-drawer@0.18.1/public/react/0.min.js)", plus "Error: Minified React error #185" (Maximum update depth exceeded).

3. Firefox network list of the wedged tab, in order: accesskey/validate 200, PATCH /api/sessions 200, GET /authentication?returnUrl=... 200 (document reload), then request 516 GET the store-drawer 0.min.js chunk with responseHeaders null and no status (never completed), then request 526 GET https://www.exito.com/ 200 whose document never committed. The same chunk URL had loaded with status 200 in the previous document. Despite 1000 console errors there is only that one chunk request, so the rejection is replayed from memory, not refetched.

4. Gecko profiler attached to the live wedged content process (3385 samples over 8 s, 100 percent busy): every sample is React work under the React scheduler MessageChannel task. Hottest stack: common.min.js:2:431632 inside Array.filter, under reducePropsToState (:2:437602), under f (:2:427130), under componentWillMount (:2:427914) and componentWillUnmount (:2:428023), under react-dom. Reading the bundle at those offsets shows react-side-effect: componentWillMount pushes this onto array l then calls f(); componentWillUnmount splices then calls f(); f() runs reducePropsToState over l mapped to props. componentWillMount samples outnumber componentWillUnmount about 2 to 1, so l grows unboundedly. A second profile started BEFORE the click captured the transition: normal recaptcha and apollo work until t=29.1 s, then 100 percent React scheduler tasks from t=30 s onward.

5. Reduced test case /app/diagnosis/testcase=eyu1rqj_.html, the same file loaded from file:/// in both browsers, with events beaconed to a local helper server so they survive the navigation:
   Chrome: 2005ms n=0 LOADED; 3101ms location.href set to /hang; 8505ms n=1 LOADED and script EXECUTED.
   Firefox: 2013ms n=0 LOADED; 3101ms location.href set to /hang; 3102ms n=1 ERROR.
   A subresource script whose response was due at about 8.5 s gets an error event 1-5 ms after the navigation starts in Firefox, while Chrome lets it complete. Both browsers were re-run twice against the final file with identical results.

Comment 4

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot