docs(browsers): document code constraints for playwright execution#351
Open
MaxFritzhand wants to merge 2 commits intokernel:mainfrom
Open
docs(browsers): document code constraints for playwright execution#351MaxFritzhand wants to merge 2 commits intokernel:mainfrom
MaxFritzhand wants to merge 2 commits intokernel:mainfrom
Conversation
…for playwright execution Add three sections to playwright-execution.mdx surfacing constraints and patterns that emerged while building an LLM-driven Playwright goal runner against Kernel's playwright.execute API: - Code constraints: rules for code passed to `code:` (no imports, no redeclaring page/context/browser, no IIFE wrapper, must end with return). Important when an LLM generates the snippet. - Composing multiple executes against one session: each call gets a fresh page/context/browser, but session state (cookies, storage, current URL) persists. Re-goto defensively between calls. - Recovering from empty results: response.success can be true with a null/empty result when a selector misses; pattern for detecting and retrying with stronger waits. All examples include both TypeScript and Python.
|
Firetiger deploy monitoring skipped This PR didn't match the auto-monitor filter configured on your GitHub connection:
Reason: This PR only modifies documentation (browsers/playwright-execution.mdx) and does not change API endpoints (packages/api/cmd/api/) or Temporal workflows (packages/api/lib/temporal) as specified in the filter. To monitor this PR anyway, reply with |
…el verification Remove the "Composing multiple executes against one session" section added in c94de29. The section claimed cookies/localStorage/URL persist across playwright.execute calls within one session, but that behavior wasn't verified against the API — the existing doc's "fresh context each time" language suggests Kernel may create a new BrowserContext per execute, which would invert the claim. Code constraints and empty-result recovery sections remain — both are independent of the state model and stand on their own.
MaxFritzhand
changed the title
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
1 participant
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.
Description
While building an LLM-driven Playwright goal runner against Kernel's
playwright.executeAPI (gist), I hit two concrete gaps in the currentbrowsers/playwright-execution.mdxdoc:playwright.executeinjectspage/context/browserinto a fresh async scope, but generated code reliably breaks the API by importing playwright, callingchromium.launch(), redeclaring those variables, or wrapping in IIFEs. The doc says what's available — not what's forbidden.success: false. Real agentic flows hitsuccess: true, result: nullfrom selector misses; that pattern deserves a template.Purely additive: only
browsers/playwright-execution.mdxmodified — two new H2 sections slotted into the existing structure (after Available variables and after Error handling). All examples include both TypeScript and Python perAGENTS.md.Implementation Checklist
Testing
mintlify devworks locally and renders the new sections cleanly.mint broken-linkspasses locally (same check this repo's CI runs).Docs
Visual Proof
Local renders of the new sections under
mint dev:Related Issue
N/A — patterns are grounded in the linked goal-runner gist rather than a prior issue.
Additional Notes
The "Recovering from empty results" section is the more opinionated of the two (prescribes a retry pattern). Easy to drop on review if it's out of scope.