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
I agree to follow the Code of Conduct that this project adheres to.
I have searched the issue tracker for a bug report that matches the one I want to file, without success.
Electron Version
30.0.4
What operating system are you using?
macOS
Operating System Version
Sonoma 14.4.1
What arch are you using?
arm64 (including Apple Silicon)
Last Known Working Electron version
No response
Expected Behavior
The documentation here describes the behavior of the contents.setWindowOpenHandler(handler).
If {action: "allow"} is returned, a BrowserWindow will be instantiated.
If {action: "deny"} is returned, a BrowserWindow will be not be instantiated. But also, the WebContents from whose renderer the window.open() function was called will show a dialog saying "Grrr! A popup blocker may be preventing the application from opening the page. If you have a popup blocker, try disabling it to open the window."
I would expect there to be a mechanism by which the "Grrr!..." dialog can be quashed (i.e. not shown).
Actual Behavior
I have not been able to find any mention of how to quash the "Grrr!..." dialog. If the dialog cannot be quashed, then {action: "deny"} cannot ever be returned from contents.setWindowOpenHandler(handler) for a window.open() call from a renderer without displaying the "Grrr!..." dialog, thus making {action: "deny"} unusable.
Testcase Gist URL
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered:
"Grrr! A popup blocker may be preventing the application from opening the page. If you have a popup blocker, try disabling it to open the window."
I've never seen this and it's not part of Chromium's own codebase - is this part of the app you're working on? It's not reproducible for me either. The window simply doesn't open, as I'd expect. I added
Preflight Checklist
Electron Version
30.0.4
What operating system are you using?
macOS
Operating System Version
Sonoma 14.4.1
What arch are you using?
arm64 (including Apple Silicon)
Last Known Working Electron version
No response
Expected Behavior
The documentation here describes the behavior of the
contents.setWindowOpenHandler(handler)
.If
{action: "allow"}
is returned, aBrowserWindow
will be instantiated.If
{action: "deny"}
is returned, aBrowserWindow
will be not be instantiated. But also, theWebContents
from whose renderer thewindow.open()
function was called will show a dialog saying "Grrr! A popup blocker may be preventing the application from opening the page. If you have a popup blocker, try disabling it to open the window."I would expect there to be a mechanism by which the "Grrr!..." dialog can be quashed (i.e. not shown).
Actual Behavior
I have not been able to find any mention of how to quash the "Grrr!..." dialog. If the dialog cannot be quashed, then
{action: "deny"}
cannot ever be returned fromcontents.setWindowOpenHandler(handler)
for awindow.open()
call from a renderer without displaying the "Grrr!..." dialog, thus making{action: "deny"}
unusable.Testcase Gist URL
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: