[BUG] Test no longer behaves as expected after inspecting on webkit

[mjhenkes]

trafficstars

Context:

• Playwright Version: 1.26.0
• Operating System: Mac
• Node.js version: 16.14.2
• Browser: Webkit
• Extra: [any specific details about your environment]

Code Snippet

This is a modified version of the example test provided by the playwright starter project.

import { test, expect } from '@playwright/test';

test('homepage has Playwright in title and get started link linking to the intro page', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);

  // After inspecting routes are no longer captured
  page.context().route('**', (route, request) => {
    console.log('route', route)
    console.log('request', request)
  })

  await page.waitForTimeout(10000)

  // Open inspector in webkit browser (i tried opening it in the test with the keyboard command of 'Meta+Alt+I', but no luck. I wonder if the browser is prevented from doing that.)

  // create a locator, the locater is created but the href attribute will be blank when checked.
  const getStarted = page.locator('text=Get Started');

  // While clicking is successful, the expected url is actually a blank string.
  page.click('text=Get Started')

  // Expect an attribute "to be strictly equal" to the value.
  // await expect(getStarted).toHaveAttribute('href', '/docs/intro');

  // Click the get started link.
  // await getStarted.click();

  // Expects the URL to contain intro.
  await expect(page).toHaveURL(/.*intro/);
});

Describe the bug

When running tests in webkit, after launching the inspector in the webkit browser, the test no longer functions as expected.

routes are no longer captured, locators have blank href values and behave strangely when clicked.

It seems like something happens to the context when the inspector is launched.

This is the command I used to recreate: npx playwright test --headed --project=webkit

after launching the test, i would right click and inspect the dom during the 10 second wait.

[rwoll]

Thanks for the report — there is indeed an issue with the debug experience here, and I can repro manually! Opening the inspector does appear to break things, so we'll need to investigate.

Your original code is missing some awaits and route.continues; however, I fixed it up:

import { test, expect } from '@playwright/test';

test('homepage has Playwright in title and get started link linking to the intro page', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
  await page.context().route('**', async (route, request) => {
    console.log('route', route)
    console.log('request', request)
    await route.continue();
  })

  await page.locator('text=Get Started').click();
  await expect(page).toHaveURL(/.*intro/);
});

Then ran:

$ npx playwright test --debug --headed --project=webkit

If I do not open the WebKit Inspector and just click play, the test runs clean (and I see the log output). However, as you report in your issue, if I open the WebKit Inspector after running the above command but before clicking play in the inspector, the test hangs once I do click play.

[rwoll]

I downgraded to 1.25.2 and the issue still happens, so this does not look like a 1.26 regression at the moment. Does that match your experience? Did this workflow used to work for you? If so, which version had it been working on? Thanks!

[rwoll]

This turns out to be an upstream bug in WebKit — its inspector does not support multiple connections (e.g. Playwright and the WebKit Inspector UI).

Adding 1.27 so we can document this limitation better.

As a workaround, you can either (1) debug on the other browsers, (2) debug off of PW traces, (3) add more logging to your router so you don't have to open inspector.

---

Internal Debug Notes: https://wksearch.azurewebsites.net/#path=%2Fhome%2Fjoe%2Fwebkit%2FSource%2FWebKit%2FUIProcess%2FInspector%2FWebPageInspectorController.cpp&line=183

[mjhenkes]

@rwoll, thanks for looking into this. As far as I know this has never worked for me, which matches up with what you've discovered.

[pavelfeldman]

Why was this issue closed?

Thank you for your contribution to our project. This issue has been closed due to its limited upvotes and recent activity, and insufficient feedback for us to effectively act upon. Our priority is to focus on bugs that reflect higher user engagement and have actionable feedback, to ensure our bug database stays manageable.

Should you feel this closure was in error, please create a new issue and reference this one. We're open to revisiting it given increased support or additional clarity. Your understanding and cooperation are greatly appreciated.