Skip to content

Make nativeWindowOpen: true the default #28511

Closed
@nornagon

Description

@nornagon
Contributor

The native window.open system has been better for quite a while now, and it resolves a lot of issues. We should make it the default and deprecate the old BrowserWindowProxy-based method.

Activity

xueqianz

xueqianz commented on Sep 1, 2021

@xueqianz

Hello, glad to see this default option, so is it needed for me to set webPreferences.nativeWindowOpen = true explicitly in electron v14.0.0?
And even if I set this option to true both for the main window and the webviews, my application still says electron: The default of nativeWindowOpen is deprecated and will be changing from false to true in Electron 15 in the console.
So how to avoid this warning?
Thanks!

xueqianz

xueqianz commented on Sep 1, 2021

@xueqianz

I found the code

if (IsUndefined(options::kNativeWindowOpen)) {
node::Environment* env = node::Environment::GetCurrent(isolate);
EmitWarning(env,
"The default of nativeWindowOpen is deprecated and will be "
"changing from false to true in Electron 15. "
"See https://github.com/electron/electron/issues/28511 for "
"more information.",
"electron");
}

which will detect the nativeWindowOpen option and throw the warning if not set, but I did set that option in all webPreferences objects in my application, but I still get that warning...
So strange.

xueqianz

xueqianz commented on Sep 1, 2021

@xueqianz

OK sorry for my bother, I think I get the root cause of this warning.
I am using the tag to make my application in multiple threads mode, and the option checking seems before the creation of the dom, am I right? So even if I set the property of the tag, it is not so in time to change the nativeWindowOpen option.
So... could you give me some tips to avoid the warning? I am not willing to fall back to v13.x.

nornagon

nornagon commented on Sep 1, 2021

@nornagon
ContributorAuthor

@xueqianz set nativeWindowOpen: true in your app to avoid the warning.

xueqianz

xueqianz commented on Sep 2, 2021

@xueqianz

@xueqianz set nativeWindowOpen: true in your app to avoid the warning.

Yes, of course, I have set this one in the main window, but it seems not working when I am using the < webview > tag. I have already set it for tag both in the webpreferences property and will-attach-webview event, it still throws that warning before the will-attach-view event is emitted.

In HTML:

<div className="class1">
          <webview className="class2"
                src="http://xxx"
                webpreferences="nativeWindowOpen=yes"
          />
</div>

In JS (will-attach-webview event):

o      webContents.on("will-attach-webview", (event, webPreferences, params) => {
               webPreferences.nodeIntegrationInWorker = true;
               webPreferences.sandbox = false;
               webPreferences.nativeWindowOpen = true;
        })

And I still get that warning before the breakpoint I set at the o position.

tomprogers

tomprogers commented on Sep 7, 2021

@tomprogers

It's awful that this is the URL provided by the electron warning, since this thread does not provide a confirmed solution for migrating.

Here is how I fixed it:

// in main thread, when instantiating a new renderer
mainWindow = new BrowserWindow({
	webPreferences: {
		nativeWindowOpen: true // ADD THIS
	}
})

Experimentation shows you don't need to define a handler for will-attach-webview to set this option, and in fact doing that alone did not eliminate the warning.

Delagen

Delagen commented on Sep 7, 2021

@Delagen

It's awful that this is the URL provided by the electron warning, since this thread does not provide a confirmed solution for migrating.

Here is how I fixed it:

// in main thread, when instantiating a new renderer
mainWindow = new BrowserWindow({
	webPreferences: {
		nativeWindowOpen: true // ADD THIS
	}
})

Experimentation shows you don't need to define a handler for will-attach-webview to set this option, and in fact doing that alone did not eliminate the warning.

This solution make webContents.setWindowOpenHandler never trigger and does not open any browser window in case of external url

xueqianz

xueqianz commented on Sep 8, 2021

@xueqianz

It's awful that this is the URL provided by the electron warning, since this thread does not provide a confirmed solution for migrating.

Here is how I fixed it:

// in main thread, when instantiating a new renderer
mainWindow = new BrowserWindow({
	webPreferences: {
		nativeWindowOpen: true // ADD THIS
	}
})

Experimentation shows you don't need to define a handler for will-attach-webview to set this option, and in fact doing that alone did not eliminate the warning.

This is the first step to solve the warning from the main webview, which I have already mentioned in my first post in this thread. But what if you use < webview > tag? I agree with you that the URL provided by the electron warning doesn't provide any solution.

xueqianz

xueqianz commented on Sep 8, 2021

@xueqianz

This solution make webContents.setWindowOpenHandler never trigger and does not open any browser window in case of external url

You can also set nativeWindowOpen: false, to use the setWindowOpenHandler, this warning is not telling you that this option is deprecated, it just infers that you need to set it explicitly if you don't want to use the native openhandler from electron 15.

theodoranice

theodoranice commented on Sep 8, 2021

@theodoranice

Thanks both works, just that I can't load the data anymore which I will see

nornagon

nornagon commented on Sep 8, 2021

@nornagon
ContributorAuthor

Just to note, it is planned to remove nativeWindowOpen: false in an upcoming version of Electron. If you are experiencing issues with setWindowOpenHandler and nativeWindowOpen: true, please open a new issue so we can get it fixed!

u2m4c6

u2m4c6 commented on Sep 14, 2021

@u2m4c6

This issue is present in the latest quick start: https://www.electronjs.org/docs/latest/tutorial/quick-start

I definitely recommend that the documentation and/or warning is updated to be more clear on what is NOT depreciated. Having to trace down a Github issue about a depreciated issue is not a great first impression for a "Quick Start."

15 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @nornagon@Delagen@tomprogers@theArina@theodoranice

      Issue actions

        Make nativeWindowOpen: true the default · Issue #28511 · electron/electron