cross-origin-iframe-probe

name	cross-origin-iframe-probe
description	Use when a drissionpage-mcp task targets an iframe such as a payment widget, challenge, SSO flow, or embedded checkout. Classifies frame document access and outer presentation evidence, then selects a DOM, viewport-coordinate, scroll, keyboard, or parent-page verification path.

Probe iframe boundaries with drissionpage-mcp

Use this Skill for an authorized iframe workflow. Cross-origin is a security boundary, but it is not by itself proof that DrissionPage cannot inspect the frame document. Make the decision from current capability evidence instead of from the URL or origin alone.

Decision procedure

1. Call frame_list and inspect each candidate's boundary, document_access, and outer evidence.
   • boundary is same_origin, cross_origin, or unknown.
   • document_access=readable means the current DrissionPage runtime can bridge the document. Use frame_snapshot or frame_find with the returned index or selector, including for a readable cross-origin OOPIF.
   • document_access=outer_only means frame DOM reads are unavailable. Keep the workflow on the iframe's outer element and parent page.
   • unknown is not success or failure. Confirm with the focused frame or element tools before choosing a path.
2. If frame_list does not enumerate the widget, use element_find_all with a specific iframe selector. Managed widgets may mount an iframe under a provider-owned Shadow DOM that top-level document.querySelectorAll() does not reveal even though DrissionPage selector lookup can resolve it.
3. Read element_state_get on the iframe selector. The returned geometry is for the outer iframe element. Preserve both coordinate-space labels:
   • rect.coordinate_space=target_document is the compatibility field.
   • Only rect.viewport_coordinate_space=top_level_viewport can be passed directly to page_click_xy, page_pointer_move, or page_pointer_drag.
   • target_document_viewport requires a higher-level coordinate conversion; do not treat it as a top-level click point.
4. Branch on presentation.coordinate_actionability before a coordinate action:
   • ready: compute the component-specific point from fresh rect.viewport_location evidence and continue.
   • off_viewport: call element_scroll_into_view, then use its after evidence or call element_state_get again.
   • hidden: wait for the widget to mount or become visible; do not click its zero or stale box.
   • covered or pointer_disabled: wait for the overlay/state transition or operate the page control that removes it, then re-observe.
   • transformed_3d: drive or wait for the page interaction that presents the target face, then re-read geometry. A static coordinate captured while the face is rotated is not actionable.
   • target_document_only: use a frame-scoped DOM action when readable, or obtain a top-level outer-frame point before coordinate input.
5. Use element_scroll_into_view.before, after, and scroll_method as the scroll receipt. Frame elements may use page_fallback; the action is usable when the after evidence is in the top-level viewport and reports the expected actionability.
6. For an outer_only widget with ready top-level geometry, use physical input through the browser pipeline:
   • page_click_xy for one fresh viewport point.
   • page_pointer_move or page_pointer_drag only when the interaction requires those gestures.
   • keyboard_press after a prior click establishes focus.
7. Verify from the parent page after every consequential action. Prefer a callback status, hidden-field presence or length, URL/title change, visible text, or another explicit element postcondition. Capture a screenshot as visual evidence, but do not expose a challenge token, Cookie, or credential.

Retry discipline

Use a bounded attempt budget. Before each retry, reacquire the frame, check its current document_access, re-read actionability and geometry, and verify that the previous attempt did not already satisfy the parent-page postcondition. Never replay stale coordinates after a refresh, layout shift, scroll, frame replacement, transform, or tab change.

Why this matters for atomic tools

frame_*, element, pointer, keyboard, wait, and screenshot tools deliberately remain separate. The Skill owns the boundary decision and the observable workflow postcondition; the MCP core supplies generic browser evidence and one explicit action per call. This keeps production challenge, payment, SSO, and embedded checkout procedures reusable without adding a provider-specific core tool.