Skip to content
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

Logical not doesn't work with browser conditions #175

Closed
DmitryShashkov opened this issue Jun 16, 2022 · 8 comments · Fixed by #800
Closed

Logical not doesn't work with browser conditions #175

DmitryShashkov opened this issue Jun 16, 2022 · 8 comments · Fixed by #800
Labels
help wanted Extra attention is needed

Comments

@DmitryShashkov
Copy link

Hi! I am trying to use not together with urlContains, like this:

import { not, urlContains } from 'wdio-wait-for';
describe('Login page', () => {
  let page: LoginPage;

  beforeAll(async () => {
    page = new LoginPage();
  });

  // a couple of `it` statements skipped

  it('should log user in and redirect them to corresponding home page', async () => {
    const submitButton = page.getSubmitButton();
    await submitButton.click();

    await browser.waitUntil(not(urlContains('login')));
    await sleep(500);

    const urlAfterRedirects = await browser.getUrl();
    expect(urlAfterRedirects).toBe(`${browser.options.baseUrl}v3/library/my`);
  });
});

And get the following error:

Error: waitUntil condition failed with the following reason: Cannot read properties of undefined (reading 'getTitle')

In the source code for urlContains, it expects the context to be passed, which works if you don't wrap it:

 await browser.waitUntil(urlContains('login')); // this works correctly

but doesn't work when wrapped in not.

I believe the situation is the same for all combinations of logical + browser conditions.

@christian-bromann christian-bromann added the help wanted Extra attention is needed label Jun 20, 2022
@christian-bromann
Copy link
Member

Hey @DmitryShashkov ,
thanks for filing the issue. This seems indeed like bug. We would appreciate any help on this so please help us out! Have a look at our contributing guidelines and reach out if you have any questions. Cheers!

@M-Hammad-Faisal
Copy link
Contributor

@christian-bromann I am looking onto this issue.

@M-Hammad-Faisal
Copy link
Contributor

M-Hammad-Faisal commented Feb 6, 2024

@christian-bromann i found the issue. When I use wait until it acts like this.

browser.waitUntil(urlContains("text")) => browser.waitUntil((this: WebdriverIO.Browser)=> {
                                           const url = await this.getUrl(); 
                                           ....
                                          })

but when i wrap it inside a function then, it becomes:

browser.waitUntil(not(urlContains("text"))) => browser.waitUntil(()=>{
                                               const condition = (this: WebdriverIO.Browser)=> {
                                                 const url = await this.getUrl(); 
                                                 ....
                                               }
                                               return !condition
) 

Here this which is WebdriverIO.Browser gets lost as it gets nested in an arrow function.

this only works in functions made with function keyword. So, in an arrow function this is just undefined.

@christian-bromann
Copy link
Member

Nice finding 👍 what would you suggest for a fix?

@M-Hammad-Faisal
Copy link
Contributor

M-Hammad-Faisal commented Feb 6, 2024

@christian-bromann we have two possible solutions:
one is that, i create logical functions with function keyword and bind the function with this word using func.call(this)
and other one is that rather than relying on this i directly use browser.getUrl. what do you suggest?

@M-Hammad-Faisal
Copy link
Contributor

i believe later one would be nicer approach. we donot need to make code more complex and wonder where is this has gone. 😆

@christian-bromann
Copy link
Member

Please go ahead and raise a PR with the approach you have in mind, I think it is better to make a final decision once there is some code.

@M-Hammad-Faisal
Copy link
Contributor

@christian-bromann I found the first approach much shorter. 😄 have a look on this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants