Skip to content

Build and publish safari browser extension - #681

Open
Siedlerchr wants to merge 74 commits into
mainfrom
safari
Open

Siedlerchr wants to merge 74 commits into
mainfrom
safari

Conversation

@Siedlerchr

@Siedlerchr Siedlerchr commented Jun 21, 2026 •

Copy link
Copy Markdown
Member
  • Create and publish and sign + notarize safari browser extensio
  • Safari extensions require some native code wrapper around the extension and need to be notarized + signed
  • native messaging happens via a Safari WebExtension Swift Bridge
  • After converting the browser code to an Xcode project, replace the Swift content and make sure our stuff is correctly added
  • Safari requires a background.html page and does not support all manifest JSON entries
  • Locally tested with Safari 26.5.2 on macOS Sequoia
  • Native messaging requires a signed and ideally notarized version of JabRef
  • Native messaging works best when JabRef is started, it can start JabRef and then will try to pass the command arguments (due to sandboxing)
  • Consolidated CI pipelines

@Siedlerchr
Siedlerchr requested a review from tobiasdiez June 21, 2026 19:19

@tobiasdiez tobiasdiez left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks a lot!

Looks like this PR contains a few unrelated/unnecessary or otherwise strange changes (AI generated??). Can you please revise this, or at least explain the need for the changes.

The main issue is the whole scripts/makefile setup. In the wxt world, you solve this by "modules" that hook into the build progress and modify/postprocess the output. You might be able to reuse https://github.com/rxliuli/wxt-module-safari-xcode or at least get inspiration how its done.

Comment thread .github/workflows/release.yml Outdated
Comment thread .github/workflows/test.yml Outdated
Comment thread src/entrypoints/options/index.html Outdated
Comment thread wxt.config.ts Outdated
Comment thread wxt.config.ts
Comment thread wxt.config.ts Outdated
@tobiasdiez

Copy link
Copy Markdown
Member

TODO: Deployment to Apple developer/registering of the extension

Can you do this please, and then configure the securities in the gh actions to actually be able to test the publish/notarize workflow.

@Siedlerchr

Copy link
Copy Markdown
Member Author

Uploading to apple app store connect works now.
Manual publishing the artifact requires some addtional setup now

koppor added a commit to JabRef/JabRef-Browser-Extension-experimental that referenced this pull request Aug 28, 2026
# Conflicts:
#	.github/workflows/test.yml
#	README.md
#	pnpm-lock.yaml
* origin/main:
  fix: limit Chrome-only permissions to non-Firefox browsers (#696)

# Conflicts:
#	wxt.config.ts
@Siedlerchr

Siedlerchr commented Aug 28, 2026 •

Copy link
Copy Markdown
Member Author

@tobiasdiez I streamlined the code, refactored it, reviewed and tested the changes again, and verified the keys against manifest v3 once more. All these changes to the keys here are done deliberately to follow v3.
I merged the PR from Ryan and then adapted the pattern here as well where it made sense for all browsers.

This PR now also enables distribution and notarization of the app outside the app store without having to wait for Apple review. On Mac, installing a browser extension is basically a separate app you install.
grafik

grafik

Would be great to have this in and then a new release across all browser

@tobiasdiez

Copy link
Copy Markdown
Member

Can you please paste the links to for the test runs for the CI workflows? Thanks!

@Siedlerchr

Copy link
Copy Markdown
Member Author

@tobiasdiez Packaging.: https://github.com/JabRef/JabRef-Browser-Extension/actions/runs/33417738312/job/99572341682?pr=681 Building the extension and the app

Manual notarizing workflow which upload it to app store connect
https://github.com/JabRef/JabRef-Browser-Extension/actions/runs/33417304774

koppor added a commit to JabRef/JabRef-Browser-Extension-experimental that referenced this pull request Aug 31, 2026
@tobiasdiez

Copy link
Copy Markdown
Member

Thanks, but I still don't get how these jobs are supposed to work / what purpose they have. It looks like:

Why can't we just have a simple matrix in the release workflow (with browser = [firefox, safari]) that runs pnpm zip (or zip:firefox) and then uses wxt submit or safari-webext-publish-action to publish?

@Siedlerchr

Copy link
Copy Markdown
Member Author

I tried to unify it a bit more:
Xcode project generation is show shared, but then the distribution differs:

Safari App Store: Xcode build -> Xcode archive/sign/package with certs for App Store → App Store Connect -> (notarization or whatever security checks happen in appstore)
Safari extension direct download: Xcode build → Developer ID signing → notarization → GitHub Release ZIP

Different distribution requires different certs and entitlements (sandboxing etc)

safari-signing-test.yml (just a simple manual/smoke test for uploading testing )

koppor pushed a commit to JabRef/JabRef-Browser-Extension-experimental that referenced this pull request Sep 1, 2026
@tobiasdiez

Copy link
Copy Markdown
Member

Do I talk again to Claude?

Safari extension direct download: Xcode build → Developer ID signing → notarization → GitHub Release ZIP

Why do we need this? So far we don't publish any build artifacts in the GH release, and nobody asked for it. Also why not simply use the build mode of safari-webext-publish-action?

@Siedlerchr

Copy link
Copy Markdown
Member Author

As I wrote earlier, these are two different things. And no, we cannot reuse the build mode of the safari-wxt-extension because it's explicit only for the app store (different entitlements, signing stuff, certs, etc.) .

Direct distribution is for downloading the app-file outside the app store (JabRef itself is also not available in the app store). It's explicit for users who don't want to use the Apple App Store or cannot use the App Store due to restrictions.
And for an easy way of testing changes. Also, Apple App Store reviews can take several days and are very strict.

Only because the other extensions are not published doesn't mean we cannot publish it as a release artifact. Does no harm, but rather improves the user experience for users who want to try out the extension with safari
run: gh release upload "${{ needs.release-pr.outputs.tag_name }}" dist/safari/jabref-browser-extension-safari.zip --clobber

* origin/main:
  chore(deps): update dependency oxlint to v1.80.0 (#730)
  chore(deps): update dependency oxfmt to v0.65.0 (#729)
  chore(deps): update dependency node to v24.20.0 (#728)
  chore(deps): update dependency globals to v17.11.0 (#727)
  chore(deps): lock file maintenance (#722)
  chore(deps): update dependency wxt to v0.21.4 (#726)
  chore(deps): update dependency vue-tsc to v3.3.11 (#725)
  chore(deps): update dependency vue to v3.5.42 (#724)
  chore(deps): update dependency vitest to v4.1.11 (#723)

# Conflicts:
#	.github/workflows/release.yml
#	.github/workflows/test.yml
#	package.json
#	pnpm-lock.yaml
koppor pushed a commit to JabRef/JabRef-Browser-Extension-experimental that referenced this pull request Sep 3, 2026
* origin/main:
  chore(deps): update pnpm/action-setup action to v6.1.0 (#734)
  chore(deps): update dependency oxlint to v1.81.0 (#733)
  chore(deps): update dependency oxfmt to v0.66.0 (#732)
  chore(deps): update dependency globals to v17.12.0 (#731)
  chore(deps): update pnpm to v11 (#676)

Co-authored-by: Junie <junie@jetbrains.com>

# Conflicts:
#	.github/workflows/release.yml
#	.github/workflows/test.yml
#	pnpm-lock.yaml
@ryan-carpenter

Copy link
Copy Markdown
Contributor

Why do we need this? So far we don't publish any build artifacts in the GH release, and nobody asked for it.

Ideally, browser extensions would be included or offered during JabRef installation for a smooth user experience. JabRef is distributed outside the app store so it seems reasonable to offer the extension the same way (like 1Password, for example, I believe). Distribution outside the app store would allow installation without an Apple ID, which is how I use macOS. I don't suppose this is a common use case.
If the Safari extension is like the Chrome/Firefox one, then building from source involves a few steps and is not very convenient.

koppor added a commit to JabRef/JabRef-Browser-Extension-experimental that referenced this pull request Sep 13, 2026
# Conflicts:
#	.github/workflows/release.yml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants