[Feature] route handler to support redirects

[tjenkinson]

Context:

• Playwright Version: 1.4.2
• Operating System: Mac
• Node.js version: 14.12.0
• Browser: All

Code Snippet

const playwright = require('playwright');

(async () => {
  for (const browserType of ['chromium', 'firefox', 'webkit']) {
    const browser = await playwright[browserType].launch({ headless: true });
    const context = await browser.newContext();
    const page = await context.newPage();

    let seenRequest = false;
    page.route('**', (route) => {
      const url = route.request().url();
      if (url.includes('account.bbc.com')) {
        seenRequest = true;
      }
      route.continue();
    });

    await page.goto('https://www.bbc.co.uk/');
    await page.click('"Sign in"');
    await page.waitForRequest(/account\.bbc\.com/);
    if (!seenRequest) {
      console.error('Did not see request');
    }
    await browser.close();
  }
})();

Describe the bug

When clicking 'sign in' there is a 302 redirect from https://session.bbc.co.uk/session to https://account.bbc.com/.

It looks like the handler is not called again with the new url on the redirect.

The docs say:

If request gets a 'redirect' response, the request is successfully finished with the 'requestfinished' event, and a new request is issued to a redirected url.

So I'm expecting the handler to be called again with the new url.

I'm expecting "Did not see request" not to be logged in my example, but it is.

[tjenkinson]

I added a test for this in #3994

It looks like a new request event is fired, but the interceptor is not called for it.

[dgozman]

As pointed in #3994, this is currently by design. Let me update this as a feature request.

[tjenkinson]

@dgozman thanks. Is there a way of providing an allow list on urls that can be accessed (including redirects) and block the rest without needing to intercept?

[dgozman]

There is no specific API for this. I think you can use proxy, although that's involved.

[tjenkinson]

Looks like that could work by not setting up a server and using bypass as the allowlist.

The network interception in Playwright is implemented on the Browser -> Network stack boundary. Once the request is in the network stack, it is going to handle the redirects and report them, but not allow intercepting them.

Any tips on how we could support this? Sounds like something browsers would need to support first before playwright could hook into it?

[dgozman]

Looks like that could work by not setting up a server and using bypass as the allowlist.

The network interception in Playwright is implemented on the Browser -> Network stack boundary. Once the request is in the network stack, it is going to handle the redirects and report them, but not allow intercepting them.

Any tips on how we could support this? Sounds like something browsers would need to support first before playwright could hook into it?

Exactly. This is specific to each browser's network stack, and requires investigation. Given the effort vs relatively small usecase, I don't expect this to be implemented in the near future.

[pavelfeldman]

Closing it for now as per above...

[btomaj]

With the growing popularity of Remix (especially with the acquisition by Shopify), the use case for handling redirects is growing. Redirecting is a common pattern in Remix. Consider reopening, and finding a solution.

[schinckel]

I'd suggest that not doing this is broken from the perspective of doing OAuth mocking too.

If you have a page in your site that should trigger the OAuth process, then that needs to redirect to the OAuth server. However, it's impossible to do this using Playwright at this stage.

Please reconsider this issue - I can see the request using page.on('request', ...) but cannot intercept that.

[younes-zeboudj]

4 years later, no workaround or solution...?

[schinckel]

I actually came up with a workaround for this (and a related bug in the WebKit Playwright implementation), where instead of returning a redirect, you instead return a 200 (or whatever status code you like), and manually handle the redirect(s) in your test.

It's far less than ideal (I think I spent around 15 lines of code, specific to the test case, and another 10+ lines of comment), but at least it works.