EAP-41664: Platform's Component matching (Components tab under Websites & Apps > Scans) failed to associate findings with a defined Component when the flagged element was rendered by client-side JavaScript after the initial page-load event - e.g. an Angular SPA rendering search results/menus after an async data fetch, as reported for ZoomInfo (a hash-routed Angular app).
Root cause: Platform's component matcher built a one-time snapshot of matching elements right after page load (document.querySelectorAll(component.cssSelector)), then looked up findings against that snapshot. An element that didn't exist yet at that instant was never in the snapshot, so it could never resolve to a component - even though its classes matched the component's CSS selector exactly. Fixed by matching live against the DOM at the moment each finding is evaluated, instead of a page-load-time snapshot.
[class*="zic-"], zic-button, zic-icon, zic-dropdown, zic-checkbox on the Digital Property under test.button-name - neither has visible text or an accessible name).COMPONENT_MATCHER_ONLY_DEFAULT_TOOL in local dev config.Present before any script runs - always resolved to the Component correctly, even with the old (buggy) matcher. Confirms this page's selector/markup is otherwise valid.
Waiting to render (simulates an SPA async data fetch / route render)…
Same classes as the control button. With the pre-fix snapshot-based matcher, this element does not exist yet when the matcher's one-time querySelectorAll runs at page load, so its finding is never associated with the Component ("<Not associated with a component>"). With the fix, this resolves to the Component correctly since matching happens live at finding-evaluation time.