-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Allow customization of bundleIdentifier for the new Electron 6+ renderer processes #4692
Conversation
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.
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. |
Supporting v5+ only is ok. Just major version of electron builder will be
released.
…On Tue, 25 Feb 2020, 08:49 Ben Standefer, ***@***.***> wrote:
@develar <https://github.com/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
<https://github.com/electron-userland/electron-builder/pull/4692/files#diff-332d71e64017661fb6f3699af2d56323R89>
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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4692?email_source=notifications&email_token=AACVTXWFAS67B2EF4I7LILDRETEPDA5CNFSM4KZCPAS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM25IIA#issuecomment-590730272>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACVTXTTTSHOWHQIMGPJDDTRETEPDANCNFSM4KZCPASQ>
.
|
bundleIdentifier
for the new Electron 6+ renderer processes
bundleIdentifier
for the new Electron 6+ renderer processesI 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.
@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 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! |
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) 🙏 |
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. |
Thanks a lot of for this improvement, it moves electron-builder forward. |
22.4.0 was released. |
Thanks @develar, you rock 💪 |
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 differentbundleIdentifier
than it saw before.Default
bundleIdentifier
values for Renderer processElectron 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 valuecom.acme.CoolApp.helper
need to be able to keep thatbundleIdentifier
for their Electron renderer process.Example usage in my app is:
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 thebundleIdentifier
had changed.