Repository navigation
chore(highlight): resolve highlights periodically in HighlightController - #42277
Conversation
Each page now has a HighlightController that keeps a list of highlighted selectors and resolves them across frames once a second, so that highlights survive navigations, newly attached frames and DOM changes. Highlights can optionally pierce frames, which is used by the recorder for user-typed selectors and aria templates. - Frame.addHighlight/removeHighlight/hideHighlight and Page.hideHighlight are replaced by the HighlightController methods. - The injected script renders highlights with a single setHighlights() call per frame, which replaces all element highlights at once. - The 'pierce' and 'noDefaultPierce' resolution options are merged into a single tri-state 'pierce' option.
Test results for "MCP"2 failed 8099 passed, 1311 skipped Merge workflow run. |
Test results for "tests 1"23 flaky51122 passed, 1220 skipped Merge workflow run. |
|
Hi, I'm the Playwright bot and I took a first look at the CI failures here. 🟢 CI is clear — both failures are pre-existing flakesThe two red MCP tests both flip verdict across hundreds of unrelated runs, and neither exercises anything this PR touches (highlights, frame selectors, screenshotter). Nothing to fix here. DetailsThis PR reworks highlight rendering ( Pre-existing flake / infra
The "tests 1" report shows only flaky/rescued results (0 real failures), so there's nothing else to triage. Triaged by the Playwright bot - agent run |
04fb72b
into
microsoft:main
Summary
HighlightControllerthat keeps the list of highlighted selectors and re-resolves them across frames once a second, so highlights survive navigations, newly attached frames and DOM changes.Frame.addHighlight/removeHighlight/hideHighlightandPage.hideHighlightare replaced byHighlightControllermethods.setHighlights()call per frame that replaces all element highlights at once.pierce/noDefaultPierceselector resolution options are merged into a single tri-statepierceoption.