Feature Request: Support UrlPattern for network interception

[nvborisenko]

https://urlpattern.spec.whatwg.org

Motivation

Currently to filter out network requests to be intercepted it happens on client side, meaning a client "enables" interception of all requests. It would be nice a client can specify "most interesting" requests to be intercepted.

[whimboo]

Hi @nvborisenko. What is missing for you for the network.addIntercept command beside the already existing optional urlPatterns argument?

[nvborisenko]

@whimboo wildcard doesn't work at all in Chrome/Firefox. Let's say I want to intercept /**/*.png requests only.

1. I remember that I should escape * with \. It used to work a while ago, but now it doesn't work at all.
2. ** probing path has never worked.

I hope I am missing something, but this issue is more about how to intercept filtered requests when "filtering happens on server side".

[OrKoN]

The current algorithm in the spec is not quite compatible with URLPattern (although it intends to be). Chrome was using the URL pattern polyfill for some time for the implementation but we removed it to ensure compatibility with the spec/WPT. It looks like Firefox does not support URLPattern still https://developer.mozilla.org/en-US/docs/Web/API/URLPattern#browser_compatibility but I think we should eventually re-write the spec and adopt URLPattern.

[OrKoN]

Looks like URLPattern is part of this year's interop https://wpt.fyi/interop-2025 which is great!

[whimboo]

The related implementation bug for Firefox is https://bugzilla.mozilla.org/show_bug.cgi?id=1731418.

[whimboo]

Each browser now has at support for URLPattern and the coverage looks pretty good as well:

https://wpt.fyi/results/urlpattern?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2025-urlpattern

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Support UrlPattern for network interception.

The full IRC log of that discussion

<jgraham> Topic: Support UrlPattern for network interception
<jgraham> github: https://github.com//issues/919
<tidoust> Henrik: Polyfill in Chrome, custom implementation in Firefox. Idea is to rather change our spec and make use of UrlPattern.
<jgraham> q+
<tidoust> ... Any concern?
<jgraham> ack next
<tidoust> ack jgraham
<tidoust> jgraham: This was the intent right from the start but UrlPattern wasn't stable yet.
<tidoust> ... I know there are compatibility concerns though. How breaking would the change be?
<tidoust> ... Maybe asking Alex in the issue would be a good way to tell!

[whimboo]

Looks like URLPattern is part of this year's interop https://wpt.fyi/interop-2025 which is great!

We have at minimum about 97% passing tests across all browsers. Maybe we should wait a bit until all the tests are passing everywhere?

@OrKoN as per the discussion yesterday in the meeting, how much breaking would such a change be? What exactly caused you to revert from the polyfill? Maybe you can still remember?

[OrKoN]

IIRC one particular issue was that the + character is accepted by the WebDriver BiDi spec as a literal but URLPattern spec does not allow it because I think it has some special meaning (kenchris/urlpattern-polyfill#132). I have not digged into the details but IIRC our WPT tests would catch it.

[jgraham]

We have at minimum about 97% passing tests across all browsers. Maybe we should wait a bit until all the tests are passing everywhere?

I don't think that should block us from starting work here. The URLPattern spec seems to be stable and have buy-in, and the sooner we can move the less likely we are to break any consumers who are depending on something that's different between URLPattern and the current spec.

[OrKoN]

To clarify: I also think we should adopt the UrlPattern even if there are some minor breaking changes to some previously accepted patterns