-
Notifications
You must be signed in to change notification settings - Fork 50
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
fix: senderId removed in Electron 28 #171
Conversation
Any ETA for this fix to land in the main branch? |
src/renderer/remote.ts
Outdated
@@ -311,7 +311,7 @@ function metaToError (meta: { type: 'error', value: any, members: ObjectMember[] | |||
|
|||
function handleMessage (channel: string, handler: Function) { | |||
ipcRenderer.on(channel, (event, passedContextId, id, ...args) => { | |||
if (event.senderId !== 0) { | |||
if (event.senderId !== 0 && event.senderId !== undefined) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this fully addresses the issue; with 28.x we see:
remote on git:main ❯ yarn install 5:00PM
yarn install v1.22.19
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
[4/4] 🔨 Building fresh packages...
success Saved lockfile.
$ tsc
src/renderer/remote.ts:314:15 - error TS2551: Property 'senderId' does not exist on type 'IpcRendererEvent'. Did you mean 'sender'?
314 if (event.senderId !== 0) {
~~~~~~~~
node_modules/electron/electron.d.ts:6002:5
6002 sender: IpcRenderer;
~~~~~~
'sender' is declared here.
src/renderer/remote.ts:315:81 - error TS2551: Property 'senderId' does not exist on type 'IpcRendererEvent'. Did you mean 'sender'?
315 console.error(`Message ${channel} sent by unexpected WebContents (${event.senderId})`);
~~~~~~~~
node_modules/electron/electron.d.ts:6002:5
6002 sender: IpcRenderer;
~~~~~~
'sender' is declared here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, senderId
has been removed, so it can only be checked for backward compatibility with older Electron versions.
If the build fails with Electron 28, can it be worked around by using event['senderId']
instead? Or should we simply remove the gatekeeper completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be in favor of using event['senderId']
for forward compatibility, personally.
Since the property has been removed with Electron 28
8f184b9
to
f76552e
Compare
It seems $ tsc
src/renderer/remote.ts:314:28 - error TS2551: Property 'senderId' does not exist on type 'IpcRendererEvent'. Did you mean 'sender'?
314 const senderId = event['senderId']
~~~~~~~~~~
test/all.ts:890:23 - error TS2345: Argument of type '"unhandledRejection"' is not assignable to parameter of type '"loaded"'.
890 process.off('unhandledRejection', onUnhandledRejection)
~~~~~~~~~~~~~~~~~~~~
Found 2 errors. I'm not a typescript expert but I wonder if |
…8, where "senderId" is removed from IpcRendererEvent
f76552e
to
393643c
Compare
Proposal: Make a custom // Backwards compatibility interface for Electron < v28
interface IpcRendererEventWithSenderId extends Electron.IpcRendererEvent {
senderId: number
}
function hasSenderId(input: any): input is IpcRendererEventWithSenderId {
return typeof input.senderId === "number"
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable given sendTo has been removed in Electron 28, so the sender of messages will always be the main process, which is what this check was trying to enforce anyway.
Looks like the tests are failing due to some other change in Electron 28. |
Sounds great - can someone please take over this pull request, who knows more of typescript than my "it's almost Javascript but with another file extension" approach... |
Latest test failures are due to electron/electron#40501 and this line in this code base: Line 388 in 642040d
|
I implemented the proposal of @felixrieseberg and now Do we need to implement a test/workaround for that in This bug is unfortunately a blocker for me, so I'd love to get it past the finish line. |
@Kilian, I don't think a fix is coming for that issue, per Sam's comment: electron/electron#40501 (comment) Sounds like |
I replaced process.mainModule with a loop to get the topmost module (module.parent is also deprecated so it's not ideal, but it does work) and logging mainModule.filename in that function gives the expected result, but I can't figure out how to update the test for it, since the test seems to use the process.mainModule logic as well: it('should search module from the user app', async () => {
expectPathsEqual(
path.normalize(await remotely(() => require('./renderer').process.mainModule!.filename)),
path.resolve(__dirname, 'index.js')
)
}) I tried updating it similarly by requiring renderer, and then looping over its parents to find the mainModule, but |
4c82813
to
85a6a96
Compare
Stale review, issue addressed
🎉 This PR is included in version 2.1.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Since the property has been removed with Electron 28