Skip to content

fix(Playwright): handle null context in proceedClick #2667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 13, 2020
Merged

fix(Playwright): handle null context in proceedClick #2667

merged 1 commit into from
Nov 13, 2020

Conversation

matthewjf
Copy link
Contributor

Motivation/Description of the PR

We have a test that opens a link in a new tab, switches to that tab and tries to click a button. Some example code:

I.click(locate('.some-button'));
I.switchToNextTab();
I.waitForElement('Get Started');
I.retry(5).forceClick('Get Started');

and we get this error intermittently (maybe 50% of our runs):

     Cannot read property '$$' of null
      at Playwright.findElements (node_modules/codeceptjs/lib/helper/Playwright.js:2152:18)
      at Playwright.findClickable (node_modules/codeceptjs/lib/helper/Playwright.js:2186:47)
      at Playwright.proceedClick (node_modules/codeceptjs/lib/helper/Playwright.js:2162:35)

After some spelunking, we discovered that sometimes this.context gets set to null. No clue how that's happening as _setPage is meant to set the context and gets called when switching tabs. However, most methods in the file are using this._getContext() but I'm not sure what the semantic difference between it and this.context is.

Applicable helpers:

  • WebDriver
  • Puppeteer
  • Nightmare
  • REST
  • FileHelper
  • Appium
  • Protractor
  • TestCafe
  • Playwright

Applicable plugins:

  • allure
  • autoDelay
  • autoLogin
  • customLocator
  • pauseOnFail
  • puppeteerCoverage
  • retryFailedStep
  • screenshotOnFail
  • selenoid
  • stepByStepReport
  • wdio

Type of change

  • 🔥 Breaking changes
  • 🚀 New functionality
  • 🐛 Bug fix
  • 📋 Documentation changes/updates
  • ♨️ Hot fix
  • 🔨 Markdown files fix - not related to source code
  • 💅 Polish code

Checklist:

  • Tests have been added
  • Documentation has been added (Run npm run docs)
  • Lint checking (Run npm run lint)
  • Local tests are passed (Run npm test)

@matthewjf
Copy link
Contributor Author

matthewjf commented Nov 10, 2020

Trying to understand this codebase a bit more, seems like this.context gets set when called using a within callback, so something like

  within('.some-selector', () => {
    I.click('Button');
  });

Wondering if we should be changing the implementation of _getContext to:

async _getContext() {
  return this.context || this.page;
}

or do a conditional check at the caller proceedClick:

let matcher = await this.context || await this._getContext();

or maybe dig deeper into why this.context is null?

Looking for some feedback.

@nitschSB nitschSB mentioned this pull request Nov 12, 2020
32 tasks
@Arhell Arhell requested a review from DavertMik November 13, 2020 19:01
@DavertMik
Copy link
Contributor

Yeah, your solution should be fine

_getContext already checks that a context element is present.

As you found out that context is used for within to specify area for search. But there is another problem there, if inside within a new page is opened or context element removed this functionality won't work. Not even sure how to fix that :)

@DavertMik DavertMik merged commit bf75294 into codeceptjs:3.x Nov 13, 2020
@DavertMik
Copy link
Contributor

Sorry I missed the time to review it so now it was released as part of 3.0.3-beta
Please update to 3.0.3-beta to have this fix applied

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants