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

Allow customization of bundleIdentifier for the new Electron 6+ renderer processes #4692

Merged

Conversation

aguynamedben
Copy link
Contributor

@aguynamedben aguynamedben commented Feb 21, 2020

Addresses #4691

Allow customization of bundleIdentifier for the new Electron 6+ renderer processes. This change addresses backward-compatibility issues arising from the Electron 6 renderer process name change (learn more). Without this, upon upgrading to Electron 6+ and building your app, macOS sees the renderer process as having a different bundleIdentifier than it saw before.

Default bundleIdentifier values for Renderer process
Electron 5 and before: com.acme.CoolApp.helper
Electron 6+: com.acme.CoolApp.helper.Renderer

macOS uses bundleIdentifier for things like keychain accesses, so apps that previously accessed things in macOS using the value com.acme.CoolApp.helper need to be able to keep that bundleIdentifier for their Electron renderer process.

Example usage in my app is:

"helperBundleId": "io.hypertools.Command-E.helperGeneric",
"helperRendererBundleId": "io.hypertools.Command-E.helper",

This maintains the bundleIdentifier value across Electron 5 and Electron 6+.

The real-world issue for app was this: In a new version of our app, our users saw a macOS permission dialog for every single keytar.get(). macOS was not trusting our renderer process because the bundleIdentifier had changed.

This is still a WIP, but this worked with my app when setting these
values in the "mac" section:

"helperBundleId": "io.hypertools.Command-E.helperBase",
"helperRendererBundleId": "io.hypertools.Command-E.helper",

There's still a bit of nastiness in that with this configuration the
other helpers (GPU, Plugin) get unnecessarily weird bundle IDs such as
io.hypertools.Command-E.helperBase, but I can clean up how these are
generated so it's more consistent. Maybe with Electron 6 it makes more
sense to allow users to specific `helperBundleIdBase`, which in my
case would be set to "io.hypertools.Command-E.helper" and allow
helpers with no override to have a sane, consistent base instead of
piggybacking on helperBundleId.

Let me know what you think. I did confirm that macOS permission pop up
key on the Bundle Identifier, not on name or anything else.
@aguynamedben
Copy link
Contributor Author

aguynamedben commented Feb 25, 2020

EDIT: Nevermind, it's easy enough to support all the cases.

@develar I'm working on this more... how many versions back of Electron must the current electron-builder support? I'm looking at options like this that were deprecated in January 2018.

Also, would it be bad to drop support for Electron 4 support? The current version is Electron 8, and as a user of Electron from Electron 3 (?) I've always found upgrading Electron to be fairly straightforward.

@develar
Copy link
Member

develar commented Feb 25, 2020 via email

@aguynamedben aguynamedben changed the title [WIP] Allow Electron 6+ Renderer helper bundle ID to be specified Allow customization of bundleIdentifier for the new Electron 6+ renderer processes Feb 25, 2020
@aguynamedben aguynamedben changed the title Allow customization of bundleIdentifier for the new Electron 6+ renderer processes Allow customization of bundleIdentifier for the new Electron 6+ renderer processes Feb 25, 2020
I based these updates on the expected output on this failing test:
https://app.circleci.com/jobs/github/electron-userland/electron-builder/2854

I presume my change affects some of the snapshots. Apologies if this
is not a kosher way to address the problem, I'm not well-versed in how
testing of electron-builder works.
@aguynamedben
Copy link
Contributor Author

@develar This is ready for review. I updated the PR description to make it more clear why I added this. It looks like there was probably some history with helperBundleId needing to be specified. This PR allows power users to customize the bundleIdentifier for Helpers as they need, but still provides good defaults for new users of electron-builder.

It should work across all version of Electron, and it's backward compatible (no breaking changes).

Let me know if there's anything else I can do to help get this merged!

@aguynamedben
Copy link
Contributor Author

I'm hoping this can be merged, is there any reason it's not likely to be merged? It's backwards-compatible, uncomplicated, and really just provides a config variable that was already available—setting the bundleId of the renderer—in a way that works with Electron 6+.

I understand you're extremely busy, I just want to understand if this is likely to be merged. We're in no rush, we have a branch working on a local machine, but given the compiled nature of electron-builder it'd be nice to have these config values in a compiled, packaged version out there the rest of my team can trust.

I appreciate your work. Oh yeah, we just donated!!! (Command E) 🙏

@develar
Copy link
Member

develar commented Mar 3, 2020

Before merge I have to release a new version to mark it a production ready (https://github.com/electron-userland/electron-builder/releases/tag/v22.3.6). And then release another version with this change as pre-release.

@develar develar merged commit 8b1cebc into electron-userland:master Mar 3, 2020
@develar
Copy link
Member

develar commented Mar 3, 2020

Thanks a lot of for this improvement, it moves electron-builder forward.

@develar
Copy link
Member

develar commented Mar 3, 2020

22.4.0 was released.

@aguynamedben
Copy link
Contributor Author

Thanks @develar, you rock 💪

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