Safari by khesed · Pull Request #71 · uBlockOrigin/uBOL-home

4 min read Original article ↗

@khesed

Output during conversion:

Warning: The following keys in your manifest.json are not supported by your current version of Safari. If these are critical to your extension, you should review your code to see if you need to make changes to support Safari:

type
default_area

Warning: Persistent background pages are not supported on iOS and iPadOS. You will need to make changes to support a non-persistent background page.

Photos:

  • Initial launch window: Initial Launch Window
  • Safari extension setting page: Safari Extension Settings Page
  • uBOL tooltip pane (can be dragged): SCR-20230907-pqmx
  • uBOL preference page: SCR-20230907-ppia
iam-py-test, mitchellknight, arjpar, 0dragosh, michaelweinold, and bmuessig reacted with thumbs up emoji erikw, dminca, aareet, ibarchenkov, twizmwazin, arjpar, Brawl345, 0dragosh, and bmuessig reacted with hooray emoji erikw, dminca, lulor, aareet, mitchellknight, alecerf, twizmwazin, arjpar, varanauskas, verhovsky, and 3 more reacted with rocket emoji

@gorhill

That is not the place or the way to make a Safari port of uBO Lite. For instance, the Firefox version is not a conversion of the Chromium version, the packages are created from build tools in https://github.com/gorhill/uBlock/tree/master/platform/mv3, and for each platform there is a folder with all the platform-specific files. A conversion tool shouldn't be needed to make a Safari version, if only to identify which files are platform-specific, and adding them to a /platform/mv3/safari folder.

Here is solely to keep track of changes between versions for officially supported, published versions of uBO Lite.

Furthermore, there need to be an investigation of API compatibility, I started to work on this here, and a Safari version would require a minimal amount of expected functionalities before an official support, otherwise the repo is going to fill with issue reports I can't address myself as I do not have access to Safari.

@khesed

That is not the place or the way to make a Safari port of uBO Lite. For instance, the Firefox version is not a conversion of the Chromium version, the packages are created from build tools in https://github.com/gorhill/uBlock/tree/master/platform/mv3, and for each platform there is a folder with all the platform-specific files. A conversion tool shouldn't be needed to make a Safari version, if only to identify which files are platform-specific, and adding them to a /platform/mv3/safari folder.

When I get a chance, I will investigate what platform specific files are necessary and add them there.

Here is solely to keep track of changes between versions for officially supported, published versions of uBO Lite.

I will familiarize myself with the uBO GitHub before making another PR, and I'll make a PR there instead of here next time.

Furthermore, there need to be an investigation of API compatibility, I started to work on this here, and a Safari version would require a minimal amount of expected functionalities before an official support, otherwise the repo is going to fill with issue reports I can't address myself as I do not have access to Safari.

Are all of those listed in that table necessary for a minimum viable Safari version?
Is it just the ? which are not investigated that you would like someone to investigate?

@khesed

@gorhill

a minimum viable Safari version

Just from the screenshots you posted, it appears a minimum viable version of Safari is not there yet. For example, Firefox version was much more functional and yet I had to wait to find a fix for the fact that Firefox's scripting API did not support the MAIN execution context to feel comfortable that it was minimally functional. There is still an issue with Firefox version that I found after I thought all was good, which is that it doesn't support DNR's domainType property yet.

Feel free to improve the wiki page if you have reliable information about what Safari supports or not, the MDN pages are not all accurate at this point and thus I used ? when I couldn't tell from MDN.

@stephenhawk8054

I think completing the wiki page is more important to reduce the chance of breakage / improve compatibility before starting another extension.

@OhYello

Does this work for the new macOS release?

@arjpar

@OhYello If by "work" you mean MVP, then no.