libs/widget-lib/src/widgetIframeLoading.ts (1)

27-54: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Retry loading state can get stuck forever — timeout isn't re-armed on reload.

The initial window.setTimeout(..., LOADING_TIMEOUT) (Lines 74-78) is set up once and only cleared in onWidgetReady. The reload click handler (Lines 41-54) never re-arms an equivalent timeout for the retry attempt. If the retried load silently hangs (never fires error, never becomes ready — exactly the scenario LOADING_TIMEOUT exists to catch), the button remains disabled with "Loading…" indefinitely with no recovery path. This directly undermines this PR's goal of giving users a visible, resolvable retry indication.

🐛 Suggested fix: re-arm the loading timeout on retry

     reloadBtn.addEventListener('click', () => {
       reloadBtn.disabled = true
       errorText.innerText = 'Loading…'

       destroy(true)
       iframe.src = 'about:blank'

       setTimeout(() => {
         iframe.src = originalSrc
         setup()
+
+        timeout = window.setTimeout(() => {
+          if (cancelled) return
+          onLoadingError()
+        }, LOADING_TIMEOUT)
       }, 100)
     })

Also applies to: 74-78

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/widget-lib/src/widgetIframeLoading.ts` around lines 27 - 54, The retry
path in onLoadingError does not re-arm the loading timeout, so a hung reload can
leave the panel stuck in the loading state. Update the reload button handler in
widgetIframeLoading.ts to start a fresh LOADING_TIMEOUT for each retry attempt,
and make sure onWidgetReady still clears whichever timeout is active. Use the
existing onLoadingError, onWidgetReady, and reloadBtn flow to keep the retry
behavior consistent.

libs/widget-lib/src/cowSwapWidget.ts (2)

177-184: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Hide the newly created iframe during the retry loading state.

When rebuildIframe is invoked, the error panel is still mounted and displaying the "Loading..." state. Because the old iframe was hidden by onLoadingError but the newly created iframe defaults to being visible, appending it immediately makes both the error panel and the blank iframe visible in the container at the same time, causing a layout clash until the widget fully loads.

Hide the new iframe immediately; onWidgetReady() will automatically reveal it once loading succeeds.

🐛 Proposed fix

   function rebuildIframe(): void {
     destroy()
 
     iframe = createIframe(currentParams)
+    iframe.style.display = 'none'
     container.appendChild(iframe)
 
     setup()
   }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/widget-lib/src/cowSwapWidget.ts` around lines 177 - 184, Update
rebuildIframe to hide the newly created iframe immediately after createIframe
and before appending it to the container. Preserve onWidgetReady’s existing
behavior that reveals the iframe after successful loading.

---

192-197: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Prevent memory leaks in event listener management.

The windowListeners array grows indefinitely because setup() and updateInterceptDeepLinks() continuously push new listeners into it, but destroy() never empties the array. In a long-lived SPA, updating parameters or triggering iframe rebuilds will accumulate detached closures.

Additionally, interceptDeepLinksListener is scoped inside setup() but pushed to windowListeners every time it updates, compounding the leak on every params update since the old listener remains in the array.

To fix both issues, align interceptDeepLinksListener with the widgetHooksListener pattern so it can be managed cleanly, and clear the windowListeners array at the end of destroy().

🧹 Proposed refactor to prevent memory leaks

First, move the listener declaration out of setup() so it isn't recreated on every rebuild (around line 96):

   let heightChangeListeners: WindowListener[] = []
   let widgetHooksListener: WindowListener | null = null
+  let interceptDeepLinksListener: WindowListener | null = null
 
   function setup(): void {

Then, stop pushing it into the array during updates (around line 121):

-    // 5. Intercept deeplinks navigation in the iframe
-    let interceptDeepLinksListener: WindowListener | null = null
-
     updateInterceptDeepLinks = () => {
       if (!iframeWindow) return
       
       // ... existing code ...
       
       interceptDeepLinksListener = interceptDeepLinks(iframeOrigin, iframeWindow)
-      windowListeners.push(interceptDeepLinksListener)
     }

Finally, properly clear all listeners in destroy():

     // Disconnect all listeners
     heightChangeListeners.forEach((listener) => window.removeEventListener('message', listener))
     windowListeners.forEach((listener) => window.removeEventListener('message', listener))
+    windowListeners.length = 0
     if (widgetHooksListener) {
       window.removeEventListener('message', widgetHooksListener)
     }
+    if (interceptDeepLinksListener) {
+      window.removeEventListener('message', interceptDeepLinksListener)
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/widget-lib/src/cowSwapWidget.ts` around lines 192 - 197, Refactor
interceptDeepLinksListener to use the same persistent, externally scoped
declaration pattern as widgetHooksListener rather than recreating and appending
it in setup() or updateInterceptDeepLinks(). Remove its windowListeners
registration, manage it directly during updates and destroy(), and clear
windowListeners at the end of destroy() after removing its listeners.