$replace fails when a script is cached already (Edit: Ignore works fine now)

[JobcenterTycoon]

I encountered a problem: $replace will fail when the unmodified script is already cached. Is there a way around this? like uncache the specific request to force the site to load the script?

Tested on: Firefox

Edit: Works fine now.

[gwarser]

Ctrl+F5. The https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/handlerBehaviorChanged api is implemented in uBO, but it's a "noop" in Firefox.

[stephenhawk8054]

Just a small, off-topic question as I don't know where to ask without opening a new discussion: Does replace work for css type?

I tried

||github.githubassets.com/assets/dark-$css,replace=/a//

and accessed any github repo, but nothing happened and logged

[gorhill]

What's the URL of the resource to replace?

---

replace= should work for any resource which is text.

[stephenhawk8054]

The STR are

1. Add ||github.githubassets.com/assets/dark-$css,replace=/a// in FF
2. Open logger and filter to css/font
3. Visit https://github.com/gorhill/uBlock

Logger does not show any modification to https://github.githubassets.com/assets/dark-a167e256da9c.css

uBO dev build 1.56.1b13

[gorhill]

The issue is that uBO cannot find the charset of the resource, and bails out in this case.

The fear is to mess up a resource which is not utf-8 encoded, so when uBO can't confirm it is dealing with utf-8 text, it bails out rather than risk causing breakage -- this is the same code path used for HTML filtering, where it is easy to mess up when not knowing the encoding of the resource.

Maybe what could be done is to change the heuristic: if the resource is not a HTML document, assume utf-8 if no encoding can be looked up.

[gorhill]

In 2018 I pointed out that Unicode encoding usage was ~90%. Now, using the same source, it's being reported at 98.2%.

Given this, I think it may be safe to just assume utf-8 for any sort of resource for which the encoding is not disclosed. HTML filtering and replace= are typically well targeted and the risk of breakage is mostly from people in the wild crafting their own filters, in which case the workaround is to drop the custom filters causing the breakage.