8.4 UI Selector Drift & Iframe Timing Fixes

How to diagnose dynamic ID changes, timing race conditions, and shadow DOM element piercing.

Same Symptom, Two Very Different Causes

A step that can’t find its target looks identical whether the real cause is a timing race (the element genuinely isn’t there yet) or a real selector drift (the page changed and the old locator no longer points at anything meaningful) – and fixing the wrong one wastes a cycle without touching the actual problem. The fast way to tell them apart: if the exact same step passed on the previous run against what should be an unchanged page, suspect timing first; if it started failing right after a deploy and keeps failing consistently, suspect a real markup change.

Working Through It in Order

Timing and race conditions first – open the Time-Travel Inspector and check the DOM snapshot taken immediately before the failing step. If the element simply isn’t rendered yet in that snapshot (a still-loading async panel, a modal mid-animation), the fix is an explicit WAIT_FOR step ahead of the action, not a different selector – CertiHeal heals a locator that stopped resolving, it doesn’t wait for one that hasn’t rendered yet, so pointing it at a timing problem won’t help.

Iframe boundaries next – a selector that worked fine when its target sat in the page’s main document can silently stop resolving the moment that same element moves inside an iframe, especially a cross-origin one that hasn’t finished its own load yet. This needs an explicit frame scope on the step, since Playwright’s default execution context doesn’t automatically reach inside a frame it hasn’t been told to look into – a longer wait alone won’t fix a selector that’s searching the wrong document entirely.

Genuine selector drift last – if timing and framing both check out and the failure is reproducible, this is CertiHeal’s job: open the Triage Drawer, check whether the case is flagged HEALED, and look at which cascade tier resolved it and whether the proposal actually targets the element you meant. A tier-1 or tier-2 recovery (data-testid, ARIA role) is safe to apply on sight; a tier-5 visual-match recovery is worth a closer look before clicking Apply Remediation Patch, since it’s the tier most likely to have matched the wrong element under ambiguous markup.

Shadow DOM last. A web app built with shadow-DOM web components usually resolves fine through CertiHeal’s text-match and DOM-proximity tiers, falling back to the tier-5 visual matcher on the rare case they don’t.

• CertiHeal Self-Healing — The five-level recovery cascade and how to triage a HEALED case.
• Time-Travel DOM Timelapse Inspector — Reading the before/after DOM diff to tell timing apart from a real change.