`trusted-replace-fetch-response` does not work when `fetch()` is called with `new URL()`

[mary-ext]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

trusted-replace-fetch-response starts matching on all fetch requests done like so

const response = await fetch(new URL(`https://selfhosted.social/xrpc/com.atproto.server.describeServer`));
const json = await response.json();

even though the filter is matching for something else, for example, this filter which spoofs geolocation requests that Bluesky attempts

bsky.app,main.bsky.dev##+js(trusted-replace-fetch-response, '/.*/', '{"countryCode":"US","regionCode":"WA"}', 'ip.bsky.app/geolocation')

A specific URL where the issue occurs.

https://bsky.app/

Steps to Reproduce

1. Add the trusted-replace-fetch-response filter rule example provided above
2. Enable "Allow custom filters requiring trust"
3. Go to https://bsky.app
4. Attempt to login

Expected behavior

It should not complain about "Bluesky Social" (or any other hosting provider/PDS you have set) being unreachable

Actual behavior

You'd get a banner saying "Unable to contact your service. Please check your Internet connection."

Thankfully Bluesky seems to have public source maps, so if we set a breakpoint on src/screens/Login/index.tsx for the serviceError check located here:

https://github.com/bluesky-social/social-app/blob/2d8e855e25e8722ee37c90a5413acd7a36d43318/src/screens/Login/index.tsx#L89-L95

You'd get this result on serviceError

This error happens because of this validation code

https://github.com/bluesky-social/atproto/blob/104e6ed37b0589cc000109dc76316be35b2257e1/packages/xrpc/src/xrpc-client.ts#L111-L114

uBO version

1.68.0

Browser name and version

Firefox 145.0.2 (archlinux package)

Operating System and version

Linux (Arch Linux, Linux lily 6.18.0-5-cachyos #1 SMP PREEMPT_DYNAMIC Sun, 07 Dec 2025 12:44:05 +0000 x86_64 GNU/Linux)

[mary-ext]

The reason I can surmise for Bluesky doing this is because TypeScript declares the url parameter in fetch(url, init) as string | URL, leading to the scenario we see here.

The only reason this works at all is behind the scenes, fetch() performs ToString on url argument if it's anything but a string (after checking it is not a Request instance.)

[mary-ext]

the one approach that seems like it would work is href:xxx, but the behavior seems to be wonky?

if we use the following filter rule

bsky.app,main.bsky.dev##+js(trusted-replace-fetch-response, '/.*/', '{"countryCode":"US","regionCode":"WA"}', 'href:ip.bsky.app/geolocation')

then I would get this bizarre result where the first request that manages to respond would get their response replaced

if I continue the execution I would expect to get another debugger pause, but it just doesn't? the unauthenticated Discover feed is empty though, not sure what's happening but then again this could also be a Bluesky thing (the app is very brittle on unexpected responses)

if I proceed to the login page, it seems to be passing through just fine? which is again, odd (but this time not Bluesky's fault, but I guess the filter rule might've defused itself?)

[mary-ext]

I do think it might just be best if the scriptlet were to normalize the first argument of fetch() to string if it's not a request, as that's the expected behavior of fetch()