[Bug]: Blob revokeObjectURL too early causes failures in WebKit when using page.route

[maxmaxme]

Version

1.49.0

Steps to reproduce

1. Clone the repository from the following link: https://github.com/maxmaxme/pw-safari.
2. Run npm install to install dependencies.
3. Run npm test to execute the Playwright test suite.
4. Observe the results across different browsers (Chromium, WebKit, Firefox).

Expected behavior

The tests should behave consistently across all supported browsers (Chromium, WebKit, and Firefox), ensuring correct handling of Blob URLs in scenarios like:

• Creating a Web Worker from a Blob URL.
• Fetching content using fetch with a Blob URL.
• Opening a new tab or window with window.open using a Blob URL.

Actual behavior

In WebKit (Safari), the following behavior is observed:

1. When page.route is used:

   • Tests fail with the following error in the WebKit console:

     Failed to load resource: The operation couldn't be completed. (WebKitBlobResource error 1.)
     

   • This error occurs in tests involving:
     • Web Workers initialized with a Blob URL.
     • Fetching content using a revoked Blob URL.
     • Opening a new tab or window with window.open using a revoked Blob URL.

2. Without page.route:

   • The tests pass successfully. Blob URLs function as expected, and no resource errors are observed in the WebKit console.
   • This confirms the issue is specific to the combination of page.route and strict handling of Blob URL revocation in WebKit.

Running 9 tests using 7 workers

  ✘  1 [webkit] › index.spec.js:9:5 › PW Blob › renders message [1] (5.9s)
  ✓  2 [chromium] › index.spec.js:20:5 › PW Blob › should open second page with "Second Page" heading (539ms)
  ✓  3 [chromium] › index.spec.js:15:5 › PW Blob › renders message [2] (541ms)
  ✓  4 [chromium] › index.spec.js:9:5 › PW Blob › renders message [1] (552ms)
  ✓  5 [firefox] › index.spec.js:9:5 › PW Blob › renders message [1] (588ms)
  ✘  6 [webkit] › index.spec.js:20:5 › PW Blob › should open second page with "Second Page" heading (5.9s)
  ✘  7 [webkit] › index.spec.js:15:5 › PW Blob › renders message [2] (5.9s)
  ✓  8 [firefox] › index.spec.js:20:5 › PW Blob › should open second page with "Second Page" heading (615ms)
  ✓  9 [firefox] › index.spec.js:15:5 › PW Blob › renders message [2] (516ms)

Notes

• This issue is not observed in Chromium or Firefox. Both browsers handle Blob URL revocation more leniently, allowing the tests to pass regardless of page.route.

Environment

System:
    OS: macOS 15.1.1
    CPU: (14) arm64 Apple M3 Max
    Memory: 194.61 MB / 36.00 GB
  Binaries:
    Node: 18.19.0 - ~/.asdf/installs/nodejs/18.19.0/bin/node
    npm: 10.2.3 - ~/.asdf/plugins/nodejs/shims/npm
    pnpm: 8.6.0 - ~/.asdf/shims/pnpm
    bun: 1.0.29 - ~/.bun/bin/bun
  IDEs:
    VSCode: 1.95.3 - /usr/local/bin/code
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: 1.49.0 => 1.49.0

[mxschmitt]

I can repro.

[yury-s]

In all three tests, the code calls revokeObjectURL before the associated resource has been fully loaded. While this might work in some browsers, there is no guarantee that the resource will have finished loading by the time the blob URL is revoked. You need to wait for a reliable signal before revoking blob URLs:

1. new Worker(url) - It is only safe to revoke the URL after receiving a message or an error from the worker, indicating it has been initialized.
2. fetch(url) - Ensure the fetch operation is complete and the URL is no longer needed before revoking. Fetch is asynchronous, so you must wait for the result.
3. window.open(blobURL) - same thing, you should wait for the new page to load before revoking the blob URL. A simple setTimeout(f, 0) is not necessarily enough.

All the tests use page.route(), which introduces extra hops in the network handling. This can slow down some operations, increasing the likelihood of failure. Since the web app relies on unspecified behavior when revoking blob URLs, this issue is not something we will address on the Playwright side. You should update the code as described above to handle blob URL revocation properly.