[BUG] "NS_BINDING_ABORTED" error in Firefox #20749
Comments
|
I can reproduce, will assign it accordingly so we take a look for the next release. Thanks for your repro! |
|
Same issue. It works fine in non-Firefox browsers. |
|
i confirm it happens with me too in google drive and most google sites i tried to use troubleshoot mode the same and it works on other browsers |
|
This behavior is consistent with what happens in Firefox when you type the url into the address bar while there is a concurrent navigation triggered by the page. I tweaked the example a little bit to make it more apparent: const sleep = (time) => new Promise((resolve) => setTimeout(resolve, time));
require('http')
.createServer((req, res) => {
if (req.url === '/a') {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(`
<body>
<script>
setTimeout(() => {
window.location.pathname = '/c';
}, 1000);
</script>
</body>
`);
} else if (req.url === '/b') {
console.log('started b');
sleep(1000).then(() => {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(`BBBB`);
console.log('finished b');
});
} else if (req.url === '/c') {
console.log('started c');
sleep(1000).then(() => {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(`CCC`);
console.log('finished c');
});
} else res.destroy();
})
.listen(3000, () => console.log('http://localhost:3000'));If you type http://localhost:3000/b so that the server output is this: Then navigation to Then navigation then navigation |
|
It's happening while opening google drive not my own server so i don't know
if it's a bug or it this something from google to promote google chrome
like they do with youtube and google image search i am not sure , i don't
mind providing you with any logs or troubleshooting steps required to do
from my end
…On Mon, 13 Mar 2023, 22:54 Yury Semikhatsky, ***@***.***> wrote:
This behavior is consistent with what happens in Firefox when you type the
url into the address bar while there is a concurrent navigation triggered
by the page. I tweaked the example a little bit to make it more apparent:
const sleep = (time) => new Promise((resolve) => setTimeout(resolve, time));
require('http')
.createServer((req, res) => {
if (req.url === '/a') {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(` <body> <script> setTimeout(() => { window.location.pathname = '/c'; }, 1000); </script> </body> `);
} else if (req.url === '/b') {
console.log('started b');
sleep(1000).then(() => {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(`BBBB`);
console.log('finished b');
});
} else if (req.url === '/c') {
console.log('started c');
sleep(1000).then(() => {
res.writeHead(200, { 'content-type': 'text/html' });
res.end(`CCC`);
console.log('finished c');
});
} else res.destroy();
})
.listen(3000, () => console.log('http://localhost:3000'));
If you type http://localhost:3000/b so that the server output is this:
started b
started c
finished b
finished c
Then navigation to c will succeed (same in Safari). If you change the
server to respond to b almost immediately, so that the output is:
started c
started b
finished b
finished c
Then navigation b wins. If the order is this:
started c
started b
finished c
finished b
then navigation b wins. With the response order as in the latter two
examples the test passes, with the first example it will fail as navigation
to c wins and that is consistent with human interaction with Firefox.
—
Reply to this email directly, view it on GitHub
<#20749 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOP4SE4EZBDZ7PRPOHZGXDW36CPVANCNFSM6AAAAAAUVKAKZM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This seems to be different than calling |
The tests document current behavior when url bar navigation competes with a js redirect. Fixes #20749
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: const test = base.extend({
page: async ({ page, browserName }, use) => {
const originalGoto = page.goto.bind(page);
page.goto = async function(url, options) {
if (!['firefox', 'webkit'].includes(browserName)) return originalGoto(url, options);
const response = await originalGoto(url, options);
const waitForURL = options?.waitForURL;
if (waitForURL) await page.waitForURL(waitForURL);
return response;
};
await use(page);
}
});
test('prevents NS_BINDING_ABORTED error', async ({ page }) => {
await page.goto('http://localhost:3000/a', { waitForURL: 'http://localhost:3000/b' });
await page.goto('http://localhost:3000/b');
});It's certainly better than adding explicit With the help of the 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 |
The behavior varies between browsers in this scenario and playwright reflects that. You can wait for the redirect to finish before starting next navigation: test('prevents NS_BINDING_ABORTED error', async ({ page, browserName }) => {
await page.goto('http://localhost:3000/a');
if (browserName !== 'chromium')
await page.waitForURL('http://localhost:3000/b');
await page.goto('http://localhost:3000/b');
});alternatively you can start the new navigation in a new page object. |
I tried this and still Firefox keeps throwing the It doesn't happen if I wait for a 400ms timeout though. Can this issue be reopened? |
|
confirmed this is still an issue in firefox |
|
Having this error when trying to load any video on YouTube, can only play them by going directly from menu to the video, trying to load the page via inserting the link doesn't load the page. |
|
fwiw, i'm using Playwright Test and was able to workaround with the expect + timeout await expect( page ).toHaveURL( 'url', { timeout: 30000 } )an example of the code that throws the error await page.goto( 'url1' )
await page.getByRole( 'button', { name: 'Login' } ).click()
await page.waitForURL( 'url2' )There are multiple redirects before getting to the URL in the This only happens in firefox. Chromium/WebKit work Hope this helps someone else and/or the issue is reopened Cheers! 🍻 |
|
Still occurs for me on Firefox browser. |
|
I still see that ERROR. Can you please reopen the ticket? |
|
This still exists in 1.41.2 |
|
Same here, still reproducible |
|
Any update on this issue? |
|
Maintainers probably do not review closed Issues. I would say we need to open a new one. |
|
Not sure if it helps, but I was able to get around this issue by opening a new tab and executing the goto there. |
|
Is there any resolution on this issue? Still seeing this error in Firefox Error: page.goto: NS_BINDING_ABORTED; maybe frame was detached? |
|
Any news about this issue? It is still reproducible. |
|
Still getting this issue. Why is this issue closed @dgozman @pavelfeldman? |
|
Same problem here in I still see that ERROR. Can you please reopen the ticket? I using |
|
@mxschmitt Can this issue be reopened? Reported by multiple users, that it still occurs. |
|
UP |
|
halp |
|
Why is this closed? |
|
Fix problems please. NS_BINDING_ABORTED. Firefox has an error when downloading and playing Youtube videos. Everything is normal in Chrome. This error started occurring 8-12 months ago |
|
I have these troubles in Outlook OWA client, too. |
|
I've also started running into this issue and would like to see it re-opened. |
|
Same issue here.... |
|
Got same issue with Firefox Version |
|
same problem, can't get to github.com from firefox. |
and others
Context:
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: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.gotoAPI will work uniformly across all browsers and page-initiated navigation can't affect subsequent navigations done bypage.goto. At least it shouldn't crash.Related issues:
The text was updated successfully, but these errors were encountered: