Preload script is not loaded for a window created with window.open

[ficristo]

• Output of node_modules/.bin/electron --version: v4.0.0
• Operating System (Platform and Version): Windows 10
• Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): 1.8.8
  Started to fail since 2.x versions.

Expected Behavior
Preload script should be loaded also for a window created with window.open and nativeWindowOpen: true, nodeIntegration: false
I don't see any warning about nodeIntegration.

Actual behavior
Preload script is not loaded.
I also see a warning about nodeIntegration enabled.

To Reproduce

$ git clone https://github.com/ficristo/electron-quick-start -b issues/16224
$ npm install
$ npm start || electron .

• Open devtools and see the warning about nodeIntegration
• Click the button on the first window
• Open devtools of the new windows and see only an console.log. Try to type window.process to find it is undefined.

Try again with electron@1.8.8

• Open devtools and see no warning about nodeIntegration
• Click the button on the first window
• Open devtools of the new windows and see a couple of console.log also related to the preload script. Try to type window.process to find it is available.

Screenshots
N/A

Additional Information
N/A

[MarshallOfSound]

Someone might correct me on this, but I'm pretty sure the "expected behavior" you're describing is actually a bug that has been fixed. windoe.open windows shouldn't inherit preload scripts by default. You'll need to explicitly give it one in the new-window event

[ficristo]

The documentation says:

If set to true, the webPreferences of child window will always be the same with parent window, regardless of the parameters passed to window.open(). Defaults to false. Note: This option is currently experimental.

So I'm expecting my options to be inherited.

If I try to add this code in the example repo:

  mainWindow.webContents.on('new-window', function (
    event, url, frameName, disposition, options, additionalFeatures, referrer
  ) {
    console.log(options);
  })

the options contains the correct values which I'm expecting.

[ficristo]

After some try this seems to have regressed between electron 2.0.11 and 2.0.12

[ficristo]

@MarshallOfSound creating a new BrowserWindow in new-window event doesn't seem to work for me.
Any workaround?

I think this issue is related to #15109 and #15207
/cc @zcbenz

[idosius]

Probably also related to #12390

You can try reverting to Electron 3.0.4. Haven't checked yet if this issue is fixed in the latest versions.

[idosius]

I've checked, it isn't fixed :(

[idosius]

Doing some more testing, it looks like any version released after 3.0.5 on 2018-10-19 has this issue, while versions released prior to that work fine

[ficristo]

@MarshallOfSound I tryed again with electron 2.0.17 and 3.0.15 and still nothing.
I noticed that on 3.0.15 now, at the start of the application (npm start), I also get

[352:0207/204900.216:ERROR:viz_main_impl.cc(195)] Exiting GPU process due to errors during initialization
[8428:0207/204900.591:ERROR:viz_main_impl.cc(195)] Exiting GPU process due to errors during initialization
[7028:0207/204900.607:ERROR:browser_gpu_channel_host_factory.cc(119)] Failed to launch GPU process.
[7028:0207/204900.622:ERROR:gpu_process_transport_factory.cc(1017)] Lost UI shared context. 

and on the devtools the message seems to have some extra newlines

Electron Security Warning (Insecure Content-Security-Policy) This renderer process has either no Content Security
      Policy set or a policy with "unsafe-eval" enabled. This exposes users of
      this app to unnecessary security risks.
 
For more information and help, consult
https://electronjs.org/docs/tutorial/security.
 This warning will not show up
once the app is packaged.

[ficristo]

Tried on v5.0.0-beta.5 with the same result.

[mskelton]

I'm experiencing this issue on 4.1.4 on macOS Mojave.

[ficristo]

@MarshallOfSound @zcbenz @miniak
I tryed to add nodeIntegrationInSubFrames: trueto the mix in the sample and seems to work (with electron 5.0.0).
Is it the expected behaviour now?

[electron-triage]

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron 6.x.y or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

[ficristo]

Same issue and same workaround with electron 8.0.1

[electron-triage]

The Electron version reported on this issue is no longer supported. See our supported versions documentation.

If this is still reproducible on a supported version, please open a new issue with any other new information that a maintainer should know.

Thank you for taking the time to report this issue and helping to make Electron better! Your help is appreciated.

[ficristo]

With version 12.0.1 I needed to add contextIsolation: false to my webPreferences to make my example work in the main but also in the renderer, and without adding nodeIntegrationInSubFrames.

[hayderma]

@electron-triage , how hard is it to make better documentation that actually can render a solution ? I have been all over this document , tried every single thing it is suggesting with no avail, it is a total contraction of itself.
This is a problem that my newly opened window can not call electronAPI no more because of this contextIsolation feature, at this point most of the devs do not care about security, just want the app to work.
As above for example @ficristo mentions that this can be resolved by setting contextIsolation: false , this is not even allowed in my app, once i do it then the contextBridge.exposeInMainWorld('electronAPI', { stops working and of course i get errors about it. why is this enforced, why can't I choose to make my app less secure?
And then as @thorsent mentions I can not use the function suggested in the documentation webContents.setWindowOpenHandler to set manually the preload for my new window, why because this does not work when contextIsolation is true.
Then what is the solution, i have been trying to resolve for 3 days now, and I can't rebuild this in a different framework as I got too involved in this app, but it is becoming clear to me why this is a very unpopular framework among devs.

[msdhaliwal]

getting the same issue in electron version 20.3.11,
where you able to find any solutions to this @hayderma @ficristo ?

[hayderma]

getting the same issue in electron version 20.3.11, where you able to find any solutions to this @hayderma @ficristo ?

I ended up using BrowserWindow (just like the one in main.js) instead of window.open, if you use this approach, which is not optimal, make sure to set parent as main window , this is the complete code for the function:

 function createChildWindow(data) {
    var childOpened=false;
    //i do not want child window opened more than once at a time, so i prevent future requests from creating more windows if one is already open
    BrowserWindow.getAllWindows().forEach(function (win) {
      console.log("window id:"+win.id);
      //the main/parent window will always have id of 1, so I know that is the main
      if (win.id > 1) {
       childOpened=true;
      }
     })
    console.log("child opened ="+childOpened);
    if(!childOpened){
      const childWin = new BrowserWindow({
       width: 800,
       height: 600,
       webPreferences: {
         nodeIntegration: true,
         enableRemoteModule: true,
         contextBridge: true,
         nativeWindowOpen: true,
         nodeIntegrationInSubFrames: true,
         parent:win, //this is the main app window created above looks something like this: win = new BrowserWindow({... make sure it is declared globally to be able to access it here
         preload: path.join(__dirname, 'preload.js')
       }
     })
     childWin.loadFile(data.url)
    }//end if

    else{
      console.log("child window opened already");
    }
  }

Also you can read more on this approach here