Playwright 1.60: within() + I.see() times out — Locator renamed from 'Locator' to '_Locator'

[mirao]

Summary

within() combined with I.see() (no explicit context argument) times out after upgrading to Playwright 1.60.

Root cause

proceedSee() in lib/helper/Playwright.js determines whether this.context is a scoped Locator or a Page/Frame using:

allText = el.constructor.name !== 'Locator'
  ? [await el.locator('body').innerText()]
  : [await el.innerText()]

Playwright 1.60 renamed the internal class from Locator to _Locator. Because of this the condition always evaluates to true, causing CodeceptJS to attempt el.locator('body') inside whatever element was passed to within() — e.g. a <tr> or a <div>. The body locator never resolves inside those elements, so the step times out.

Error observed:

TimeoutError: locator.innerText: Timeout 30000ms exceeded.
Call log:
  - waiting for locator('xpath=(...//tr)[position()=1]').first().locator('body')

Affected versions

• Playwright: 1.60 (introduced by the internal rename)
• CodeceptJS: 3.7.8 (latest at time of writing)
• Works correctly on Playwright 1.59

Fix

Replace the fragile constructor.name check with a stable public-API distinction: Page and Frame both expose url(), Locator intentionally does not.

// Before
allText = el.constructor.name !== 'Locator'
  ? [await el.locator('body').innerText()]
  : [await el.innerText()]

// After
allText = typeof el.url === 'function'
  ? [await el.locator('body').innerText()]
  : [await el.innerText()]

typeof el.url === 'function' produces the correct branching on all Playwright versions (Page/Frame have always exposed url(); Locator has never had it), so it is fully backward-compatible.

Reproduction

within(locate('.some-div'), () => {
  I.see('Expected text'); // times out in Playwright 1.60
});

---

This issue was identified and reported by Claude (Anthropic's AI assistant), on behalf of the user.

[mirao]

Root cause detail: esbuild bundling, not an intentional rename

After digging into the Playwright repository, the _Locator name is not an intentional public API change — it is a side-effect of Playwright 1.60 switching its distribution format from individual compiled files to a single esbuild bundle.

In Playwright ≤ 1.59 the package shipped lib/client/locator.js containing:

class Locator { ... }

In Playwright 1.60 (introduced by #40057 and #40074, merged 2026-04-06/07) the package now ships a single lib/coreBundle.js. esbuild prefixes class names with _ when it needs to avoid naming conflicts during bundling, so Locator silently became _Locator at line ~15901 of that bundle.

This means:

1. The rename was unintentional from Playwright's side — constructor.name was never a supported API contract.
2. Other class names could be renamed by esbuild in future releases for the same reason.

This further reinforces why the fix should use a stable public-API distinction (typeof el.url === 'function') rather than patching for _Locator specifically.

[mirao]

Correction: FrameLocator case also needs to be handled

The initial fix using typeof el.url === 'function' broke within({ frame: ... }) because FrameLocator has neither url() nor innerText(), causing it to fall into the el.innerText() branch and crash:

TypeError: el.innerText is not a function

There are four possible types for this.context in CodeceptJS, with different method availability:

Context type	url()	innerText()	Correct branch
Page	✓	✓	locator('body').innerText()
Frame	✓	✓	locator('body').innerText()
FrameLocator	✗	✗	locator('body').innerText()
Locator	✗	✓	el.innerText()

Only Locator uniquely has innerText() without url(). The corrected fix:

// Before (broken in PW 1.60)
allText = el.constructor.name !== 'Locator'
  ? [await el.locator('body').innerText()]
  : [await el.innerText()]

// After (handles all four context types)
allText = typeof el.url !== 'function' && typeof el.innerText === 'function'
  ? [await el.innerText()]
  : [await el.locator('body').innerText()]