Closed gunir closed 11 months ago
Try:
||voz.vn$csp=worker-src 'none'
and unregister service worker from about:serviceworkers
.
Try:
||voz.vn$csp=worker-src 'none'
and unregister service worker from
about:serviceworkers
.
Thank you, it worked!
Test video: https://streamable.com/o3ly9l
Should we have a workaround for this issue ?
Header Editor also has this HTML Filtering capability but it doesn't have this issue, it can still modify above webpage even with that serviceworker running.
@gwarser I think we need this https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData#permissions ?
From Firefox 95, to use this API to intercept requests related to the loading of service worker scripts, the "webRequestFilterResponse.serviceWorkerScript" permission is also required.
@gwarser I think we need this https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData#permissions ?
From Firefox 95, to use this API to intercept requests related to the loading of service worker scripts, the "webRequestFilterResponse.serviceWorkerScript" permission is also required.
@gorhill
@stephenhawk8054 uBO filters only main HTML document, does not touch any script or service worker.
What stephenhawk is suggesting is an enhancement if we want to intercept and block web-workers without having to resort to "CSP" filters.
Adding these permissions [to manifest] does not help. Something more need to be done to filter these requests.
Permissions open the way for the enhancement, Obviously, specific code needs to be added to make it happen, hence an enhancement.
Adding these permissions [to manifest] does not help. Something more need to be done to filter these requests.
I have a working code for Header Editor addon, I don't know why but it DOES work without manually changing CSP "worker-src", this enhancement will make using/writting HTML Filter more bearable.
This is my code:
Name: VozClean
Modify response body
Regular Expression
^.*?voz.vn/$
Custom function: return val.replace(/<div class="p-body-sidebar">[\s\S]*?<\/footer>/, '<!-- CLEANED -->');
Screenshot:
Should we mark this as enhancement and reopen ? It's no longer an issue but improvement is nice.
A little looks as AdGuard replace, then filter will works only after publish new add-on (if all others ideas fails and uBo add support).
https://adguard.com/kb/general/ad-filtering/create-own-filters/#replace-modifier
I checked on the latest free AdGuard add-on 4.2: it can handle it for Firefox:
||voz.vn^$replace=/<div class="p-body-sidebar">[\s\S]*?<\/footer>/<!-- CLEANED -->/
Unfortunately, AdGuard and their HTML Filtering cannot remove the element without damaging the entire DOM of the website.
I would suggest checking if the add-on "Header Editor" is actually working with action "VozClean" before browser parse HTML.
Unfortunately, AdGuard and their HTML Filtering cannot remove the element without damaging the entire DOM of the website.
This is very bad imo, but they will fix for sure, they're professional after all.
But well, talking about uBO's HTML Filtering, I don't mind removing worker src manually but it's such a hassle for end-users, HTML Filtering is very beneficial, its actually improve page loading speed by skipping network connections of removed contents entirely.
In this tested, you can see removing vs hiding that sidebar saved a lot of bandwidth: Removing (116 total requests):
Hiding (141 total requests):
HTML Filtering is a bit advanced, but I believe it worth our cares to enhance it further to make it more user-friendly.
My 2 cents.
I would suggest checking if the add-on "Header Editor" is actually working with action "VozClean" before browser parse HTML.
It does, if you want proof, take this filter: https://github.com/uBlockOrigin/uBlock-issues/issues/2833#issuecomment-1732592498
Look at this result pic and check in view-source:
It looks uBo replace https://github.com/gorhill/uBlock/commit/7c3e060c01 have same problem. In AdGuard replace worked fine 2 months ago without kill service worker.
I think this is fixable by giving precedence to content-type
when evaluating whether to html-filter a response.
I think this is fixable by giving precedence to
content-type
when evaluating whether to html-filter a response.
Beautiful and thank you, the recent replace
filter loves this fix!
Prerequisites
I tried to reproduce the issue when...
Description
HTML Filter is not working as expected, I used a fresh profile, fresh uBlock install, check my reproduce steps.
A specific URL where the issue occurs.
https://voz.vn/
Steps to Reproduce
voz.vn##^.p-body-sidebar
to My FilterI've recorded a video, please check it: https://streamable.com/ek1var
Expected behavior
The right sidebar should always get cleaned.
The right sidebar contains many iframes, that's why it's better to remove with HTML Filter
##^
than hiding with Element Hiding##
I've recorded a video, please check it: https://streamable.com/ek1var
Actual behavior
The right sidebar only disappear if I Ctrl+F5, which is pointless because it's a hard refresh, but it shows up again if I use F5.
I've recorded a video, please check it: https://streamable.com/ek1var
uBO version
1.52.0
Browser name and version
Firefox ESR 115
Operating System and version
Windows 10