## Summary
When logging into mail.ru (which uses VK ID as its auth provider), the id.vk.ru/auth iframe loads successfully (all network requests return 200), but the authentication flow never completes. Instead, it restarts in a loop with a new code_challenge every ~10-15 seconds, and the login form on mail.ru hangs indefinitely with a loading spinner. This does not happen with stock Playwright using the same Chromium version/profile approach.

## Environment

• CloakBrowser version: 0.4.5 (also reproduced on 0.4.3 before upgrading)
• OS: Windows 10/11 x64
• Chromium version: 146.0.7680.177 (visible in UA string in logs)
• Python wrapper (launch_persistent_context_async)
• Target site: https://mail.ru (login flow via VK ID / auth.mail.ru/api/v1/vkid_auth/start)

## Steps to Reproduce

1. Launch a persistent context with CloakBrowser:

ctx = await launch_persistent_context_async(
    user_data_dir="profiles/test_profile",
    headless=False,
    no_viewport=True,
    humanize=True,
    ignore_https_errors=True,
    args=["--window-size=1600,900"],
)
page = await ctx.new_page()
await page.goto("https://mail.ru", wait_until="networkidle", timeout=60000)

2. Click "Войти" (Login) on the mail.ru homepage.
3. Observe the modal opens with an infinite loading spinner and never resolves.

## Expected Behavior
The VK ID auth iframe should complete its handshake with the parent window (mail.ru) and either show the login form or restore an existing session, exactly as it does in stock Playwright.

Actual Behavior

The iframe (id.vk.ru/auth?...) reloads repeatedly with a freshly generated code_challenge parameter each time, roughly every 10-15 seconds, and the loading spinner on the parent page never disappears.

Comparison: Playwright vs CloakBrowser (same machine, same network conditions)

Stock Playwright — auth flow completes, VK ID polling sustains:

[PW][302] https://account.mail.ru/login/
[PW][302] https://auth.mail.ru/api/v1/vkid_auth/start
[PW][200] https://id.vk.ru/auth
[PW][200] https://static.vk.ru/vkid/1.1.1368/auth.js
[PW][200] https://persiq.vk.com/vkid/getEvents/auth_common_9068800865393890659
[PW][200] https://persiq.vk.com/vkid/getEvents/auth_common_9068800865393890659

persiq.vk.com/vkid/getEvents is called repeatedly — this is the polling endpoint that confirms the iframe is alive and the parent is listening. The login form renders correctly.

CloakBrowser — auth flow restarts in a loop:

[CB][302] https://account.mail.ru/login/
[CB][302] https://auth.mail.ru/api/v1/vkid_auth/start
[CB][200] https://id.vk.ru/auth
[frame_navigated] https://id.vk.ru/auth?...code_challenge=WQbYedjQePdyzGPa0ILo2bM18NbnDLaoQV6Hdk8UyJg...
[CB][200] https://static.vk.ru/vkid/1.1.1368/auth.js
[CB][200] https://persiq.vk.com/vkid/getEvents/auth_common_9000000001165586455 <- appears ONCE
[CB][302] https://account.mail.ru/login/ <- restarts
[CB][302] https://auth.mail.ru/api/v1/vkid_auth/start
[CB][200] https://id.vk.ru/auth
[frame_navigated] https://id.vk.ru/auth?...code_challenge=KwJuABsyd77KIzdeLrvjXENCVO2a9oYOMLkDryVsALc... <- DIFFERENT code_challenge, full restart
[CB][302] https://account.mail.ru/login/ <- restarts again
[CB][302] https://auth.mail.ru/api/v1/vkid_auth/start
[CB][200] https://id.vk.ru/auth
[frame_navigated] https://id.vk.ru/auth?...code_challenge=9RXHF1hNlPaobbi_Tr8JnZbWGelcCqsa5iRnS5InN-Y... <- restarts a third time

persiq.vk.com/vkid/getEvents fires exactly once across the whole session and is never called again, even though the iframe keeps reloading with new challenge parameters. This pattern (one-shot getEvents call followed by full iframe restart) strongly suggests the iframe never receives a confirmation postMessage from the parent window — so VK ID's internal logic assumes the parent isn't listening and tears down/restarts the flow.

What I've already ruled out

I went through the following diagnostic steps before concluding this is likely an iframe/postMessage issue rather than a network/proxy/CORS issue:

1. ORB (Opaque Response Blocking) — initially media-trend.mail.ru/challenge.html was failing with net::ERR_BLOCKED_BY_ORB. Adding --disable-features=OpaqueResponseBlockingV01,OpaqueResponseBlocking resolved this specific failure (challenge.html now returns 200), but the core spinner issue persisted.
2. HTTP/2 — pms.mail.ru (push/realtime server) was failing with net::ERR_HTTP2_SERVER_REFUSED_STREAM on an early test. Adding --disable-http2 resolved this, but again, the spinner issue persisted.
3. CORS — added --disable-web-security to rule out cross-origin fetch blocking on media-trend.mail.ru/api/.... No change to the core issue.
4. Proxy/SSL — not in use for this specific test; reproduced with no proxy configured at all.
5. Network-level comparison — ran a side-by-side test with stock Playwright (playwright.chromium.launch_persistent_context) and CloakBrowser against the same site in the same session. Network responses are nearly identical (same 200s, same redirect chains) — the only meaningful divergence is the absence of sustained persiq.vk.com/vkid/getEvents polling and the repeated code_challenge regeneration in CloakBrowser.
6. postMessage listener — injected a window.addEventListener('message', ...) into every frame via frameattached/framenavigated events to log any cross-frame messages. No [postMessage] log lines were ever captured during the CloakBrowser run, despite the iframe being confirmed present and active (frame_navigated events fire correctly for id.vk.ru/auth).
7. stealth_args=False — disabled all default stealth arguments to isolate whether the issue originates in the wrapper's flag composition or the binary itself. The loop behavior was identical: persiq.vk.com/vkid/getEvents fired once, followed by the same code_challenge regeneration pattern. This points to the binary-level patches as the likely source rather than anything controlled by launch-time flags.

Suspected Root Cause

Given that:

• The iframe is created and loaded successfully (network-wise)
• VK ID's polling endpoint (persiq.vk.com/vkid/getEvents) is hit exactly once instead of continuously
• No postMessage events are observed between the iframe and parent frame
• The flow keeps regenerating code_challenge and restarting, consistent with VK ID's client-side logic timing out while waiting for a parent acknowledgment
• The behavior is identical with stealth_args=False, ruling out wrapper-level flags as the cause

...this looks like it could be related to one of CloakBrowser's source-level (C++) patches affecting cross-frame communication (postMessage, window.parent access, or iframe sandboxing behavior) — possibly connected to the sandbox-related warnings also seen in the console during this flow:

An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.

This warning appears repeatedly throughout the session on various ad/tracking iframes as well, suggesting the patched binary may be handling sandboxed iframe behavior differently than stock Chromium in a way that could plausibly interfere with legitimate cross-frame messaging used by VK ID's auth widget.

Questions for maintainers

1. Are there any known patches affecting postMessage, window.parent/window.opener access, or iframe sandbox attribute handling?
2. Is there a way to verify/inspect whether postMessage calls are being silently dropped or intercepted by the stealth layer?
3. I tested with stealth_args=False to rule out the JS/flag-level stealth layer as the cause — the issue persisted identically (same one-shot getEvents call followed by code_challenge regeneration loop). This suggests the relevant behavior is baked into the patched binary itself rather than controlled by wrapper-level flags. Can you confirm whether any of the 49/57 source-level patches touch cross-frame messaging or sandboxed iframe behavior?