playwright: [BUG] "NS_BINDING_ABORTED" error in Firefox
Context:
- Playwright Version: 1.30.0
- Operating System: Mac/Ubuntu
- Node.js version: 18.12.1
- Browser: Firefox
Code Snippet
See repository with minimal reproducible example: https://github.com/wentwrong/pw-firefox-ns-binding-aborted
Describe the bug
When you navigate to page A and then immediately navigate to page B (using page.goto), if page A asynchronously navigates itself to another URL then navigation to page B will fail in Firefox with the following error:
1) [firefox] › bug.spec.js:3:1 › goto should not fail with the "NS_BINDING_ABORTED" error ========
page.goto: NS_BINDING_ABORTED; maybe frame was detached?
=========================== logs ===========================
navigating to "http://localhost:3000/b", waiting until "load"
============================================================
3 | test('goto should not fail with the "NS_BINDING_ABORTED" error', async ({ page }) => {
4 | await page.goto('http://localhost:3000/a');
> 5 | await page.goto('http://localhost:3000/b');
| ^
6 | });
7 |
See detailed logs here: https://github.com/wentwrong/pw-firefox-ns-binding-aborted/actions/runs/4124609214/jobs/7124068636
Currently there are no ways to workaround it except adding explicit page.waitForTimeout() after first navigation which is a little hacky and unreliable.
I expect that the page.goto API will work uniformly across all browsers and page-initiated navigation can’t affect subsequent navigations done by page.goto. At least it shouldn’t crash.
Related issues:
- https://github.com/microsoft/playwright/issues/2061
- https://github.com/microsoft/playwright/issues/13640
- https://github.com/microsoft/playwright/issues/12912
- https://github.com/microsoft/playwright/issues/5775
- https://github.com/microsoft/playwright/issues/11677
- https://github.com/microsoft/playwright/issues/8437
- https://github.com/microsoft/playwright/discussions/14063
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 8
- Comments: 18 (4 by maintainers)
confirmed this is still an issue in firefox
I understand that, but the problem is that there is no way to supress this error, and seeing it doesn’t provide any useful information for the user.
For now we are experimenting with the following approach:
It’s certainly better than adding explicit
page.waitForTimeout()-s in every test, but it still doesn’t feel like a proper way of handling this issue. First of all, we need to know in advance on which page the redirect chain will end up on, so that we can wait until this page is open to be sure that the navigation requests will not be canceled by the subsequentpage.goto()invocations. And secondly, it slows down tests in Firefox and Webkit browsers.With the help of the
page.on('requestfailed')event handler we can catch this error, but unfortunately there is no way to tell Playwright to suppress it, although most users who encountered this error would like to be able to.I’be really glad to hear on how this error is supposed to be solved or worked around, because as I stated in the issue message, as a user of Playwright framework I expect that the
page.goto()API will work uniformly across all browsers. And even if opening a new page in a browser leads to cancellation of previous navigations, it should not fail the test whatsoever because it’s not a sensible default behaviour.Still occurs for me on Firefox browser.
The behavior varies between browsers in this scenario and playwright reflects that. You can wait for the redirect to finish before starting next navigation:
alternatively you can start the new navigation in a new page object.
I still see that ERROR. Can you please reopen the ticket?
fwiw, i’m using Playwright Test and was able to workaround with the expect + timeout
an example of the code that throws the error
There are multiple redirects before getting to the URL in the
page.waitForURLThis only happens in firefox. Chromium/WebKit work
Hope this helps someone else and/or the issue is reopened
Cheers! 🍻
This seems to be different than calling
page.goto()when the page is doing js redirect. Please file a separate issue with detailed reproduction steps.