Related issues (this first-pass PR does not fully fix all of these, but it should help):

• dealing with security issues while trying to automate against Azure Portal #700 (azure nested iframes)
• Failed to locate element: Locator.element_handle: Error: strict mode violation: locator(...) resolved to 2 elements #853 (salesforce nested iframes)
• Element Not Clickable (Likely due to Shadow-Root or i-Frame) #566 (amazon iframes)
• I had tried to run Captcha.py but not working as expected #923 (captcha.com demo iframes)
• Iframe Support?? #443 (some other payment gateway iframe)

This PR attempts to break CORS from the agent's perspectve and allow buildDOMTree.js to traverse cross-origin iframes just like it currently does non-cross-origin iframes. Unfortunately the same approach used for same-origin frames is not possible, browser security forces us to go around the wall via playwright instead, but this introduces several new hurdles.

We have to create a new id translation mapping that mutates all the subframe generated DOM trees to reconnect the references to cross-origin parents & children. We also have to deterministically merge/offset all the IDs and update child id references to prevent conflicts, without introducing any dependency between frames during tree generation to keep it parallel.

The main challenges

• playwright doesn't deterministically provide all the frames in the first place‼️ with identical settings some pageloads page.frames contain cross-origin frames, exit, retry and the next time it doesn't, retry a few times then it does, etc. there is a race or timing issue
• iframes arent guaranteed to have any id, name, or unique src url, the standard API to pierce and find a nested iframe only accepts name= or url= as lookup params and nothing else.
• iframes and their content can be added/removed/updated multiple times per second by JS, and their context handles and all child handles (and potentially nested frames) break any time they navigate
• non-cross-origin iframes can nested inside cross-origin iframes and vice versa up to 3x deep

In an ideal world we'd want

• every <iframe /> to have a stable and globally unique name="..." or url="..." attr
• which means page.frame('name') works to pierce and get that specific iframe even if nested
• it also lets us merge separate DOMTree maps without conflicts because every frame ends up with a unique xpath /html/body/iframe[somename]/html/body/iframe[othername]
• all frames should inject buildDOMTree.js in parallel for speed, and output should be merged at the end. building it frame by frame and passing the growing indexOffset counter between them serially is too slow

Approaches tried

• pre-tagging every iframe encountered with a data-browser-use-iframe-id={idx} attr doesn't work because JS frameworks like react/vue/etc redraw the element immediately, also doesn't solve the issue of how to pierce parent frames to find the element later
• using playwright to trick the browser into thinking it's a same-origin domain by rewriting the iframe request and response URLs too complex/browser security prevents it without crazy root CA hacks
• passing an indexOffset counter into buildDOMTree.js so the IDs it generates don't conflict with the parent frame forces them to run serially, or forces us to switch to a longer ID format w/ random ids (which might break vision, the system prompt, or lower LLM success)
• give up on nested and non-unique iframes and only support top-level cross-origin and same-origin iframes I got this 1/2 working but it's slow and makes some pages more buggy
• ⭐️ SIMPLEST SOLUTION: if any visible (non-ads) cross-origin iframe is present on the page, simply open the url for it in a new tab and treat it like a separate page, with a special title telling the LLM it's a popup that should be treated as part of the previous page