You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
"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.
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.
@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.
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 renderermainWindow=newBrowserWindow({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.
Sxribe, shehan-kv, stabback, ryanlelek, johnbeech and 4 more
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 renderermainWindow=newBrowserWindow({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
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 renderermainWindow=newBrowserWindow({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.
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.
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!
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."
dcpiccolo, johnbeech, michael-erskine, SimonLundberg and mifi
Activity
xueqianz commentedon Sep 1, 2021
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 sayselectron: 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 commentedon Sep 1, 2021
I found the code
electron/shell/browser/web_contents_preferences.cc
Lines 144 to 152 in 5530497
which will detect the
nativeWindowOpen
option and throw the warning if not set, but I did set that option in allwebPreferences
objects in my application, but I still get that warning...So strange.
xueqianz commentedon Sep 1, 2021
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 commentedon Sep 1, 2021
@xueqianz set
nativeWindowOpen: true
in your app to avoid the warning.xueqianz commentedon Sep 2, 2021
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 andwill-attach-webview
event, it still throws that warning before thewill-attach-view
event is emitted.In HTML:
In JS (
will-attach-webview
event):And I still get that warning before the breakpoint I set at the
o
position.tomprogers commentedon Sep 7, 2021
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:
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 commentedon Sep 7, 2021
This solution make webContents.setWindowOpenHandler never trigger and does not open any browser window in case of external url
xueqianz commentedon Sep 8, 2021
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 commentedon Sep 8, 2021
You can also set
nativeWindowOpen: false
, to use thesetWindowOpenHandler
, 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 commentedon Sep 8, 2021
Thanks both works, just that I can't load the data anymore which I will see
nornagon commentedon Sep 8, 2021
Just to note, it is planned to remove
nativeWindowOpen: false
in an upcoming version of Electron. If you are experiencing issues withsetWindowOpenHandler
andnativeWindowOpen: true
, please open a new issue so we can get it fixed!u2m4c6 commentedon Sep 14, 2021
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