Invoke Query returns promise in next then in Cypress 12

[farlandlee]

Current behavior

I am using Gleb's tutorial here, https://glebbahmutov.com/blog/cypress-automation/, to automatically grant permissions in the Chrome browser to the clipboard. I then test to make sure the permission has been granted. But in Cypress 12, the result variable in the code snippet below is a promise and thus result.state is undefined and the test fails. This test works under 11.2.0

cy.window()
.its('navigator.permissions')
.invoke('query', { name: 'clipboard-read' })
.then((result) => {
    expect(result.state).to.eq('granted');
});

I have also tried writing the test this way:

cy.window().its('navigator.permissions')
.invoke('query', { name: 'clipboard-read' })
.its('state').should('eq','granted');```

state is also undefined in this case.

Desired behavior

Cypress should resolve the promise and return the result object defining clipboard-read which would have a state property.

Test code to reproduce

Here is a repo:
https://github.com/farlandlee/cypress-test-tiny

Cypress Version

12.3.0

Node version

v16.18.1

Operating System

MacOS 13.1 (22C65)

Debug Logs

No response

Other

No response

[farlandlee]

I tried to include the debug logs, but they were too long

[emilyrohrbough]

@farlandlee In v12.0.0, one of the breaking changes was:

• The .invoke() command now throws an error if the invoked function returns a promise. If you wish to call a method that returns a promise and wait for it to resolve, use .then() instead of .invoke(). Addressed in #24417.

It indeed appears that Invoke no longer waits for the promise to resolve, updating your example to the follow works:

    cy.window()
    .its('navigator.permissions')
-   .invoke('query', { name: 'clipboard-read' })
+   .then((api) => api.query({ name: 'clipboard-read' }))
    .its('state').should('be.oneOf', ['prompt', 'granted', 'denied'])

It seems the issue here is that invoke did not throw an error when .invoke('query', { name: 'clipboard-read' }) returned a promise. Seems we are not correctly erroring to communicate this behavior. Verified with v12.3.0.

[farlandlee]

@emilyrohrbough thank you! I read that change, but as I was not getting an error I thought it did not apply in this situation. I will adjust my code accordingly. Much appreciated!

[trainoasis]

@emilyrohrbough this indeed fixes it, thanks! 🙌🏼 I think this issue can be closed :)

[emilyrohrbough]

@trainoasis Glad to hear this worked for you!