Release 0.5.0#8
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46da08ff06
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| animations: "disabled", | ||
| caret: "hide", | ||
| fullPage: false, | ||
| mask: page.locator("input,textarea,select"), |
There was a problem hiding this comment.
With any explicit checkpoint step, this passes a single Locator to page.screenshot, but Playwright documents the mask option as Array<Locator>; the client maps that array before taking the screenshot, so a Locator object here throws before the checkpoint artifacts are written and the journey step is marked failed. Wrap the locator as [page.locator("input,textarea,select")] so checkpoint capture works.
Useful? React with 👍 / 👎.
| const count = await locator.count(); | ||
| if (count !== 1) throw new Error(`Expected exactly one matching element, found ${count}`); |
There was a problem hiding this comment.
When a target is inserted asynchronously after navigation or a state change, locator.count() is just an immediate snapshot and does not honor the step timeout, so click, fill, and expect-visible can fail with found 0 even though the element appears within the configured timeout. Poll or wait for attachment before enforcing uniqueness so journeys work against common SPA/render-delayed UIs.
Useful? React with 👍 / 👎.
| const submitsForm = await locator.evaluate((element) => { | ||
| const form = element.closest("form"); | ||
| if (!form) return false; |
There was a problem hiding this comment.
For valid HTML where a submit button/input is outside the form but associated via a form="..." attribute, closest("form") returns null, so the write-action guard allows the click and the browser submits the associated form. This breaks the documented default of blocking form-submit controls for those layouts; check the element's associated form as well as ancestors.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f247aa4572
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| route: (() => { try { return routeOf(page.url()); } catch { return null; } })() | ||
| }); | ||
| await captureCheckpoint(`failure-${index + 1}`, index).catch(() => {}); | ||
| if (!journey.continueOnFailure) stop = true; |
There was a problem hiding this comment.
When continueOnFailure is true and a click or redirect leaves the candidate origin, the failed step is recorded but this leaves stop false, so subsequent journey steps execute on the off-origin page before the next origin check fails. Since the request guard still permits public off-origin URLs, this can interact with an unintended site despite the same-origin journey boundary; stop or recover whenever the failure was an origin violation.
Useful? React with 👍 / 👎.
| const current = await executeJourneyStep(page, step, { | ||
| timeoutMs, | ||
| candidateBase, | ||
| allowPrivateNetwork, | ||
| minimumAccessibilityScore: journey.minimumAccessibilityScore, |
There was a problem hiding this comment.
For journeys that intentionally submit a form, assertClickAllowed/assertKeyAllowed only allow submit controls or Enter-in-form when context.allowWriteActions is true, and their error message points users to an allow-write-actions option. This context never supplies that flag, and the CLI does not parse it either, so form-submission journeys always fail with no available override.
Useful? React with 👍 / 👎.
1 participant
No description provided.