Safari issues to resolve for a minimally working uBOL

Update

2025-05-13

There is now a beta version for Safari on both macOS and iOS, which can be installed through TestFlight, click the following link:

https://testflight.apple.com/join/JjTcThrV

Description

Continuing from #52, which had become too large, to focus on remaining technical issues.

To build a local version of uBO Lite for Safari, in a bash-compatible shell and at repo root (corrected as per @ramsey's post below):

git clone git@github.com:gorhill/uBlock.git
cd uBlock/
make mv3-safari

The extension will be at dist/build/uBOLite.safari/, and can be sideloaded into Safari 18.4+ following the instructions at Temporarily install a web extension folder in macOS Safari

Remaining issues (will update as needed):

• excludeMatches in scripting.RegisteredContentScript appears to be ignored
  • This causes lower filtering mode such as Basic or No filtering to still be filtered through injected CSS and scriptlets
  • Fix has been merged into WebKit: "excludeMatches" array in scripting.registerContentScripts() API is ignored WebKit/WebKit#43398
• DNR's allowAllRequests has no effect, even though it's documented as being supported: https://developer.apple.com/documentation/safariservices/blocking-content-with-your-safari-web-extension#Add-rulesets-to-your-extension-and-manifest
  • This prevents the ability to disable filtering on site
  • Ghostery is using a different rule than allowAllRequests
  • This requires Safari-specific code paths
  • Being addressed by Safari: https://bugs.webkit.org/show_bug.cgi?id=291872
• Redirects to local web_accessible_resources do not work, see https://ublockorigin.github.io/uBOL-home/tests/test-filters.html ("Advanced network filters")
  • Removing leading / in resource paths in manifest fixed the issue. Removing the leading / does not affect uBOL in other browsers.
• Lot of regex-based filters are rejected compared to Chromium version
  • https://bugs.webkit.org/show_bug.cgi?id=260970
• The zapper does not work, possibly related to the web_accessible_resources issue above
  • https://bugs.webkit.org/show_bug.cgi?id=246617
  • Using a workaround in Safari: use src attribute before inserting iframe into DOM
  • Being addressed by Safari: https://bugs.webkit.org/show_bug.cgi?id=291696
• youtube.com does not load (blank page). It loads if I disable the Default ruleset -- so there is a rule in there which is causing the issue. However Safari does not support finding which specific rule is blocking which specific resource URL
  • Caused by the filter ||googlesyndication.com^$domain=blogto.com|youtube.com. Conversion to DNR rule put googlesyndication.com into condition.requestDomains, so it appears requestDomains is either not supported, or interpreted differently in Safari.
  • Reference material: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/4971ZS9cI7E
  • A very specific mitigation has been added to prevent the breakage, but there is a need to understand how Safari interprets requestDomains since that property is used in thousands of DNR rules.
  • Being addressed by Safari: https://bugs.webkit.org/show_bug.cgi?id=289205
• Strict-blocking does not work
  • https://bugs.webkit.org/show_bug.cgi?id=256054
  • Though possibly it could be that special regex characters are being used (e.g. ^), which are interpreted literally by Safari DNR's engine, see Regular expressions in DNR API (regexFilter) w3c/webextensions#344 No, JS's RegExp is literally used to match regexFilter

Help to investigate these issues is welcome.

uBO Lite version

Local, build from command line

Browser name and version

Safari 18.4

Operating system and version

MacOS 15.4