Unhandled TypeError: "[object Object]" cannot be parsed as a URL in #checkSsoSilently messageCallback when a non-string postMessage arrives

[silentDjay]

Describe the bug

I'm running keycloak-js on an SPA using

init({ onLoad: 'check-sso', silentCheckSsoRedirectUri });

#checkSsoSilently registers a message listener and passes event.data straight into #parseCallback → #parseCallbackUrl, which calls new URL(urlString). The listener guards only on event.origin and event.source, not that event.data is a string. A non-string message posted from inside the same-origin iframe (common with mobile autofill/password-manager injection) passes both guards, so new URL({...}) throws "[object Object]" cannot be parsed as a URL.

Two aggravating factors:

1. #parseCallback(event.data) is outside the try/catch, and messageCallback is async → the throw surfaces as an unhandled rejection (onunhandledrejection) instead of hitting the catch.
2. Since it throws before the try, the cleanup (removeChild / removeEventListener) never runs, so the listener stays attached and every subsequent injected object message throws again — until the genuine string message resolves the promise. Auth still succeeds, but monitoring floods with recurring TypeErrors.

#checkSsoSilently registers a message listener and passes event.data straight into #parseCallback → #parseCallbackUrl, which calls new URL(urlString). The listener only guards on event.origin and event.source; it does not verify that event.data is a string.

If any script running inside the (same-origin) silent-check-sso iframe posts a non-string message (an object) to parent — common with mobile password-manager/autofill injection — the message passes both guards, and new URL({...}) throws:

TypeError: "[object Object]" cannot be parsed as a URL.

Version

26.2.4

Expected behavior

A stray non-string postMessage that happens to originate from the iframe should be ignored, not crash with an unhandled rejection, and should not leave the listener attached.

Actual behavior

Net effect: authentication still succeeds (the real string message eventually resolves), but the app emits recurring unhandled TypeErrors that flood error monitoring (Sentry, etc.).

How to Reproduce?

1. Configure an SPA with onLoad: 'check-sso' and a valid silentCheckSsoRedirectUri.
2. After the iframe is created but before/around the genuine callback, have any same-origin script inside the iframe post a non-string message, e.g.:

   // running inside the silent-check-sso iframe's window
   parent.postMessage({ some: 'object' }, location.origin)

   (In the wild this is triggered by browser password-manager/autofill injected scripts, so no app code is needed.)
3. Observe an unhandled TypeError: "[object Object]" cannot be parsed as a URL.

Anything else?

This has been reported mainly from mobile browsers (Chrome/iOS WebKit) where password managers / autofill inject scripts into same-origin frames.