[Bug]: {action: "deny"} from contents.setWindowOpenHandler(handler) is unusable
safris opened this issue · 2 comments
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 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
"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
mainWindow.webContents.setWindowOpenHandler((details) => {
return {
action: 'deny'
}
})
to the main process and window.open()
to the renderer process on macOS.
@codebytere, you're absolutely right. This bug was indeed outside of Electron. I apologize for raising this here, and thank you for looking into it 🙏