fix(helpers): restore substring matching in waitInUrl - #5682
Open
nlespiaucq wants to merge 1 commit into
Open
Conversation
codeceptjs#5451 wired resolveUrl() into waitInUrl alongside waitUrlEquals. For waitUrlEquals that is correct — a strict comparison needs the relative path resolved against the configured base url. For waitInUrl it silently turned a documented substring match into an origin-anchored one: const expectedUrl = resolveUrl(urlPart, this.options.url) // '/users' -> 'https://app.example.com/users' return currUrl.indexOf(expectedUrl) > -1 // scheme+host+port must now match exactly So I.waitInUrl('/users') breaks after a redirect to a different host, port or scheme, and a partial match such as I.waitInUrl('user=test') resolves to <base>/user=test and never matches /info?user=test. Compare against the raw urlPart again in Playwright, Puppeteer and WebDriver. waitUrlEquals is left untouched. The existing test asserted only inside catch, so it passed vacuously whenever the wait unexpectedly succeeded — which is how this shipped. It now fails on a missing timeout, plus a new case pinning the regression. docs/migration-4.md listed waitInUrl among the methods that resolve relative urls while its own example said the opposite; corrected. Co-authored-by: Claude <claude@anthropic.com>
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
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.
Motivation/Description of the PR
#5451 introduced
resolveUrl()and wired it intowaitInUrlalongsidewaitUrlEquals. ForwaitUrlEqualsthat is correct — a strict comparison genuinely needs the relative path resolved against the configured base url. ForwaitInUrlit silently turned a substring match into an origin-anchored one:I.waitInUrl('/users')after a redirect to another host/port/schemeI.waitInUrl('user=test')on/info?user=test<base>/user=test, times outI.waitInUrl('/app')withurl: 'http://localhost'but live on127.0.0.1This also contradicts the method's own docs —
docs/webapi/waitInUrl.mustache("Waiting for the part of the URL to match the expected") anddocs/migration-4.md, which literally statesI.waitInUrl('/users')"matches any URL containing /users". The docs described the old behavior; only the code changed.Fix:
waitInUrlcompares against the rawurlPartagain in Playwright, Puppeteer and WebDriver, and reports it unresolved in the timeout message.resolveUrlimports stay —waitUrlEqualsstill uses them.This is strictly more permissive than current
4.xfor every realistic input (resolveUrl('/x', base)always ends in/x, so anything matching the resolved form also matches the raw form), so no currently-passing usage regresses.waitUrlEqualsis deliberately untouched. #5451 also tightened it from substring to strict equality in Playwright/Puppeteer; that matches the method's name, its docs and WebDriver's long-standing behavior, so it is out of scope here.No issue was filed for this — it was found while upgrading. Resolves the
waitInUrlhalf of the behavior change in #5451.Applicable helpers:
Applicable plugins:
Type of change
Checklist:
npm run docs)npm run lint)npm test)Notes on the two unchecked boxes:
npm run docscurrently crashes on4.xbefore this PR as well —TypeError: Cannot read properties of undefined (reading 'members')atrunok.cjs:417indocsAppium. Unrelated to this change and not fixed here. Regeneration is not needed anyway:docs/webapi/waitInUrl.mustacheis unchanged (it already described the restored behavior), so the generateddocs/helpers/*.mdare byte-identical.docs/migration-4.mdis hand-written and was updated in this PR.npm testwas not run end to end;test:unitwas (769 passing, 0 failing), buttest:restandtest:runnerwere not. The helper suites that actually cover this change were run instead — see below.Testing
The existing test placed its
assertonly insidecatch, so it passed vacuously whenever the wait unexpectedly succeeded — which is how this regression shipped. It now fails on a missing timeout, and a new case pins the bug.Reverting only the helper change reproduces the regression in its own words:
Verified locally against the PHP test app:
waitInUrl/waitUrlEquals/waitCurrentPathEqualsnpm run test:unitnpm run lintThe WebDriver leg was run through webdriverio's self-managed chromedriver rather than the Selenium container, which cannot complete its BiDi websocket handshake through Docker Desktop on macOS; CI covers the Selenium path.
🤖 Generated with Claude Code