refactor: move waitForEventsAfterAction to McpPage#1780
Merged
OrKoN merged 12 commits intoChromeDevTools:mainfrom Apr 1, 2026
Merged
refactor: move waitForEventsAfterAction to McpPage#1780OrKoN merged 12 commits intoChromeDevTools:mainfrom
OrKoN merged 12 commits intoChromeDevTools:mainfrom
Conversation
…pdate all callers
OrKoN
reviewed
Apr 1, 2026
Service worker evaluation should not trigger DOM stability wait since service workers don't interact with the page DOM. Move the waitForEventsAfterAction call to the normal page evaluation path only, removing the page parameter from performEvaluation.
…erAction Service worker evaluation was incorrectly skipping waitForEventsAfterAction entirely. It should use the selected page's waitForEventsAfterAction helper so that throttling settings are respected, while still being called via the page-based McpPage method rather than the removed McpContext method.
executeInPageTool is a definePageTool handler and should use request.page to target the correct page, not context.getSelectedMcpPage() which would apply the wrong throttling settings in multi-page scenarios.
- Remove unused context parameter from navigatePage handler - Use import type for PredefinedNetworkConditions in WaitForHelper
wolfib
pushed a commit
that referenced
this pull request
Apr 1, 2026
Splits out from #1244 per review feedback. 'waitForEventsAfterAction' previously lived in 'McpContext' and always used the selected page's CPU/network throttling settings. With pageId routing, a tool can target a different page than the selected one, meaning wrong throttling multipliers were applied. Moving the method to 'McpPage' fixes this: each tool now calls 'page.waitForEventsAfterAction(...)' and gets the correct page's emulation settings. 'getNetworkMultiplierFromString' is extracted to 'WaitForHelper.ts' to avoid a circular import (McpContext → McpPage already exists). Unblocks #1777.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Splits out from #1244 per review feedback.
'waitForEventsAfterAction' previously lived in 'McpContext' and always used the selected page's CPU/network throttling settings. With pageId routing, a tool can target a different page than the selected one, meaning wrong throttling multipliers were applied.
Moving the method to 'McpPage' fixes this: each tool now calls 'page.waitForEventsAfterAction(...)' and gets the correct page's emulation settings.
'getNetworkMultiplierFromString' is extracted to 'WaitForHelper.ts' to avoid a circular import (McpContext → McpPage already exists).
Unblocks #1777.