MWPW-206368 - Fix cancel button stuck screen, stray redirects and extra assets

[DavidKHahn]

Summary

Cancel on Acrobat verb pages (pdf-to-word, excel-to-pdf, etc.) could intermittently stop returning the user to the drop zone after several upload → Cancel cycles, and could trigger stray redirects/reloads. Root causes were leftover state from previous (cancelled) uploads. Fixes in workflow-acrobat/action-binder.js and workflow-acrobat/upload-handler.js:

1. Stale progress-bar timer — showTransitionScreen() now clears the previous instance's progress-bar timer before creating a new TransitionScreen.
2. Completion race — if an upload finishes just after Cancel, don't proceed to redirect (abortSignal.aborted || !isUploading guard, mirroring uploadMultiFile()).
3. Silent abort (no extra asset / error toast) — a user-aborted direct upload now returns quietly instead of falling back to a second /api/v1/asset create + connector call (HAR showed 13 extra assets for 13 cancels). Timeouts still surface as errors (NetworkUtils never throws AbortError for them).
4. Cancel during redirect-URL fetch — stop after handleRedirect() if the upload was cancelled meanwhile.
5. Self-reload guard — continueInApp() bails out if Cancel cleared redirectUrl during its 500 ms delay. Previously this reloaded the page to ?UTS_Uploaded&redirectTime&undefined (dropping unitylibs=).
6. Stale operations — cancelAcrobatOperation() clears operations, so a later event can't redirect with a cancelled upload's data.
7. Single RedirectReady listener — DCUnity:RedirectReady is registered once instead of on every acrobatActionMaps() call (listeners were stacking since [MWPW-170867]Wait for event dispatched from DC acom code to redirect to acrobat web #334).

Test plan

• Unit tests: upload-handler.test.js 73/73, action-binder.test.js 256/256 (new tests for every fix above)
• Mutation tested: reverting each fix individually fails its test
• Lint: no new errors
• Manual on www.stage.adobe.com with PR code (Requestly, below): 6–7 upload → Cancel cycles, each returned to the drop zone; final upload converted successfully

PR code served on stage (307 → branch)	Branch action-binder.js 200	Converted after repeated cancels

QA instructions

⚠️ Don't use ?unitylibs= on www.stage.adobe.com (it resolves to hlx.live, which returns 403 → Unity doesn't load). And on stage--dc--adobecom.aem.live test pages, anonymous uploads can land on an empty Acrobat page after a successful redirect (Acrobat 401 / "UTS_Redirect cookie not found" — guest cookies can't cross from aem.live to .adobe.com). That happens on stage code too and isn't related to this PR. Use the setup below instead.

One-time setup (Requestly)

1. Install the Requestly Chrome extension; in chrome://extensions → Requestly → Details → enable Allow in Incognito.

2. Open https://app.requestly.io/rules → New rule → Redirect Request (no Requestly sign-in needed):

   • Rule name: unity-902
   • If request: URL + RegEx → paste exactly (including the slashes):

     /^https://www\.stage\.adobe\.com/unitylibs/(.*)/
     

   • Redirects to: select Another URL → paste:

     https://mwpw-206368-cancel-button-fix--unity--adobecom.aem.live/unitylibs/$1
     

   • Make sure the Enabled toggle (top right) is on → click Save rule.

   It should look like this:

   

Test

1. Close all incognito windows, open a fresh one (stay signed out). Open DevTools → Network, check Preserve log, filter action-binder.
2. Open https://www.stage.adobe.com/acrobat/online/pdf-to-word.html
3. Confirm action-binder.js shows 307 with Location on mwpw-206368-cancel-button-fix--unity--adobecom.aem.live (PR code is loaded).
4. Upload a PDF → click Cancel → confirm you're back on the drop zone. Repeat 6–10× with different files, including cancelling late in the progress bar.
5. Upload once more and let it finish → you should land on Acrobat's "Your file is ready" page with the converted .docx.
6. Before/after: toggle the Requestly rule Off to test current stage code.

Expected: Cancel always returns to the drop zone; no unexpected redirect/reload, no error toast; final upload converts.
Notes: Cancel clicked after the redirect to Acrobat has started (100%) can't be stopped by the page — expected. If a "free account" sign-in wall appears, fully quit Chrome (Cmd+Q) and retry. Turn the Requestly rule off when done.

JIRA: https://jira.corp.adobe.com/browse/MWPW-206368

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run all PSI checks
• Re-run failed PSI checks
• Re-sync branch

Commits

• 561a424 ✅ (latest)

[asonnalagi]

@DavidKHahn @Ruchika4 Still noticing the issue in branch.
https://stage--dc--adobecom.aem.live/drafts/nala/acrobat/online/test/pdf-to-word?unitylibs=mwpw-206368-cancel-button-fix

upload.mp4

[DavidKHahn]

@DavidKHahn @Ruchika4 Still noticing the issue in branch. https://stage--dc--adobecom.aem.live/drafts/nala/acrobat/online/test/pdf-to-word?unitylibs=mwpw-206368-cancel-button-fix

upload.mp4

hi @asonnalagi thanks for testing this edge case. In your video, Cancel button was clicked after the bar hit 100%. At that point the redirect to Acrobat has already started so landing on Acrobat's "Converting…" screen is expected (that screen is owned by the Acrobat web app).

Please for now re-test by clicking Cancel before 100% using ?unitylibs=mwpw-206368-cancel-button-fix and make sure that parameter stays in the URL each time.

Suggestion: as a follow-up, we could hide or disable Cancel once the bar reaches 100% so users aren't shown a cancel that can't take effect. I'll check with design.

[asonnalagi]

Validated in the below URL.
https://stage--dc--adobecom.aem.live/drafts/nala/acrobat/online/test/pdf-to-word?unitylibs=mwpw-206368-cancel-button-fix.

• Cancel with 0% loader is not showing error on Acom page.
• Cancelled more than 10 times, not redirecting to product.
• After 100% load UI is redirecting to product
• Cancel at 100% is redirecting to product.

End to end validation will be done on stage.

[aem-code-sync]

	Page	Scores	Audits	Google
📱	/unitylibs/		Lighthouse returned error: NO_FCP. The page did not paint any content. Please ensure you keep the browser window in the foreground during the load and try again. (NO_FCP)
🖥️	/unitylibs/		Lighthouse returned error: NO_FCP. The page did not paint any content. Please ensure you keep the browser window in the foreground during the load and try again. (NO_FCP)