IpcRenderer does not execute normally in preload.js

[ChinaLiuxiaosong]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • 7.1.3
• Operating System:
  • Windows 10 (1909)
• Last Known Working Electron version:
  • never

Expected Behavior

In preload.js, ipcRenderer.on can work when script loading.

Actual Behavior

In preload.js, ipcRenderer.on does not work while script loaded.

To Reproduce

https://gist.github.com/8beadb34f2123ee942968494edf439d0

Screenshots

[reZach]

I'd like to add some detail, it appears ipcRenderer does not include all methods when executing in a preload.js script. This is problematic, because there is no other way to pass an ipcRenderer to a renderer process. What does this mean? Renderer process cannot use ipcRenderer.on("", {}).

preload.js

const { contextBridge, ipcRenderer } = require("electron");

console.log(ipcRenderer);
contextBridge.exposeInMainWorld(
    "electron",
    {
        ipcRenderer: ipcRenderer
    }
);

What gets displayed in the console:

[reZach]

@sofianguy @ChinaLiuxiaosong

It appears the ipcRenderer is only an EventEmitter instance in the preload.js There must be some lifecycle code/event/gen that populates the various properties for an ipcRenderer, and this process isn't happening in the preload script.

[reZach]

I would gladly help if someone could point me in the right direction, my familiarity with the source code is very low.

[reZach]

Another note, if you preload the ipcRenderer, using the contextBridge, even in a renderer process you get a subset of the methods (only the EventEmitter methods as described above), not the entire method set as mentioned in the docs. So the issue is not with the ipcRenderer but with the context bridge.

[reZach]

There is no issue with contextBridge, simply the preload script itself, see MVP where you can test the bug (Electron v.7.1.8): https://github.com/reZach/broken-preload-example

[reZach]

It looks like the problem is here:

electron/lib/renderer/init.ts

Lines 42 to 52 in ee58d60

	const ipcEmitter = new EventEmitter()
	const ipcInternalEmitter = new EventEmitter()
	v8Util.setHiddenValue(global, 'ipc', ipcEmitter)
	v8Util.setHiddenValue(global, 'ipc-internal', ipcInternalEmitter)
	v8Util.setHiddenValue(global, 'ipcNative', {
	onMessage (internal: boolean, channel: string, args: any[], senderId: number) {
	const sender = internal ? ipcInternalEmitter : ipcEmitter
	sender.emit(channel, { sender, senderId }, ...args)
	}
	})

. Can anyone explain why we need to use an EventEmitter here?

[reZach]

Update on the sample repo. @ChinaLiuxiaosong It turns out ipcRenderer.on works fine in the preload, at least in my sample repo. Please view the following gist for more details. My test repo has also been updated to show you can call ipcRenderer.on in the preload.

However - you still cannot call ipcRenderer.on(channel, args) from the renderer process. This is desired because it is not feasible to put all logic regarding the ipcRenderer in the preload. ie. I have a i18n library that needs to send ipc messages to the main process in order to save translation files to disk. This library exists in the renderer process, and in order for the translation files to be saved it needs to call out to the main process (which has access to fs). Upon finishing writing translation files, the library must finish executing it's code. Without ipcRenderer.on(channel, args) available in the renderer process, this process is impossible.

Again, the MVP test repo has been updated and can replicate this problem for someone to replicate the issue.

[reZach]

I've posted a $230 bounty on this issue for prioritization, thanks!

[reZach]

Turns out, the problem is contextBridge. A possible solution is to not use contextBridge and simply load the ipcRenderer to the renderer process the "old-way". More discussion is in that thread.

[MarshallOfSound]

@reZach That is not a solution and is a terrible idea. The problem is not the context bridge.

Copying your desired state from your other issue, this is how you do it correctly:

Details

renderer

class LibraryClass {
    constructor(myValue = 1) {
        this.classValue = myValue;

        window.electron.ipcRenderer.on("response", (IpcRendererEvent, args) => {
            if (args.success) this.classValue++;
        });
    }

    send() {
        window.electron.ipcRenderer.send("request", {
            data: this.classValue
        });
    }
}

main

let win = new BrowserWindow({...});

ipcMain.on("request", (IpcMainEvent, args) => {
    // Use node module (ie. "fs");
    // perhaps save value of args.data to file with a timestamp

    win.webContents.send("response", {
        success: true
    });
});

Isolated Preload

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('myapi', {
  request: (data) => ipcRenderer.send("request", {
    data,
  }),
  onResponse: (fn) => {
    // Deliberately strip event as it includes `sender` 
    ipcRenderer.on('response', (event, ...args) => fn(...args));
  }
}

Renderer

class LibraryClass {
    constructor(myValue = 1) {
        this.classValue = myValue;

        window.myapi.onResponse((args) => {
            if (args.success) this.classValue++;
        });
    }

    send() {
        window.myapi.request(this.classValue);
    }
}

Main Process

let win = new BrowserWindow({...});

ipcMain.on("request", (IpcMainEvent, args) => {
    // Use node module (ie. "fs");
    // perhaps save value of args.data to file with a timestamp

    win.webContents.send("response", {
        success: true
    });
});

Things to note

1. Exposing a minimal API surface from the preload to the renderer, just two helpers, not the entire ipcRenderer module
2. Core business logic still remains in the renderer (LibraryClass) just the stuff that requires Electron APIs lives in the isolated preload
3. Even with this set up you should validate the incoming arguments are valid / what you would expect when you are handling the event in the main process

Final Note

@reZach I'd ask that you stop spamming these issues as your issue is not this potential bug rather user issues with how the APIs work.