[Copilot]

I.waitForText with a context compared text differently from I.see depending on the locator. For a CSS context it used Playwright's text= selector, which normalizes whitespace. For an XPath context (including anything built with .at(n)) it used innerText. The same text could therefore pass for I.see, fail for I.waitForText, and change result when .at(1) was added to the locator.

Changes

• lib/helper/Playwright.js (waitForText):
  • The CSS-context branch no longer uses locator(${css} >> text=...).
  • It now resolves the elements with this._locate(locator) and reads innerText ?? textContent, the same extraction proceedSee uses.
  • It polls every 100 ms until waitTimeout and keeps the existing Text "..." was not found on page after N sec. error.
  • The XPath branch and the no-context branch are unchanged.
• test/helper/webapi.js: adds a waitForText case using new Locator('#text').at(1) as the context.

I.waitForText('0 . 8 8', 1, '#app')            // CSS context, now matches innerText like I.see
I.waitForText('0 . 8 8', 1, locate('#app').at(1))  // XPath context, same result

Notes for review

• I have not run the new test or the existing suite. Electron failed to install and no Playwright browsers are available in this environment, so this needs CI.
• grabTextFrom is untouched and still returns textContent, so the \n 1\n 2\n 3\n result in the issue's first example persists. Switching it to innerText would change return values for existing users, so I left that for a separate decision.
• The added test only covers the .at(1) path on /dynamic. It does not reproduce the span or Bootstrap scenarios from the issue.

• Fixes Inconsistent assert behavior for text #5278