Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari MV3 Prototype #1804

Draft
wants to merge 20 commits into
base: main
Choose a base branch
from
Draft

Conversation

sammacbeth
Copy link
Collaborator

This is a prototype of how we might add a new Safari MV3 build target, using Safari's new MV3 Webextension APIs. Comments on the implementation:

  • We have to bundle TDS block rules as static rulesets. This is because requestDomain support does not currently work (as of Safari 16.3 and Safari Technology Preview 165), so we end up with more rules due to this limitation. There is a hack in place to avoid using remote TDS to make this work.
  • I've had to manually patch to config to disable GPC and AMP protection, as those DNR rules throw as unsupported when we try to register them. It would be better if we could split out config rules per feature to be able to control their inclusion better from the code.
  • The XCode project part of the extension is included in browsers/safari. After building the extension, we copy it into browsers/safari/safari-mv3/Shared\ \(Extension\)/Resources/, which this project reads to pack the 'extension app'.
  • I've created a new entrypoint as I had to avoid importing events.js - that file uses many APIs that are not present on Safari (e.g. webRequest) so importing it would break the build.
  • As we can't use webRequest listeners for tab tracking, and not all webNavigation events are available, I've had to extract that code that was in events.js into a features/tab-tracking.js file that keeps tabManager updated to tab changes from the available events.
  • All DNR rules are passed through a converted (convertDNRRuleset in safari-compat.js) that fixes up rules to work in Safari.
  • As injecting content-scripts on document_start is not supported, I'm doing dynamic injection on webNavigation.onCommited, which seems to be faster than document_idle.
  • Multiple things still don't work (user allowlisting being the most major). See https://github.com/sammacbeth/mv3-compat-tests for a rundown of the issues that affect us.

browserName = ''
} else {
browserName = '-' + browserName + (chrome?.runtime.getManifest().manifest_version === 3 ? 'mv3' : '')
}
return `https://staticcdn.duckduckgo.com/trackerblocking/config/v2/extension${browserName}-config.json`
// return `https://staticcdn.duckduckgo.com/trackerblocking/config/v2/extension${browserName}-config.json`
return `https://pyrite-scarce-agenda.glitch.me/staticcdn/trackerblocking/config/v2/extension${browserName}-config.json`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lately I've been wondering if we should propose a QWD or similar ability to save this to extension config through the extension dev tools.

Editing list-editor doesn't stick long enough either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants