electron: [Bug]: Mouse clicks on target="_blank" links inside webview don't seem to give an event

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 feature request that matches the one I want to file, without success.

Electron Version

15.0.0-beta.3

What operating system are you using?

Other Linux

Operating System Version

Fedora 34

What arch are you using?

x64

Last Known Working Electron version

14.x.x

Expected Behavior

Clicking a link in a webview with the “_blank” attribute should result in any kind of event somewhere, but it doesn’t seem to work since enabling “nativeWindowOpen”.

Actual Behavior

No event is triggered, not the new-window on the webview, nor the setWindowOpenHandler on it’s webContents. Other link events and window.open do show up in the handler and the new-window event listener, so that’s not it either.

Testcase Gist URL

No response

Additional Information

You can make it work again for now by disabling the unreliable “nativeWindowOpen” on both the BrowserWindow and it’s containing webview.

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 1
Comments: 16 (9 by maintainers)

Commits related to this issue

WebView: Enable allowpopups. This is required for Electron ≥ 15 to continue invoking our new window handler (handleExternalLink), following the nativeWindowOpen migration. https://github.com/electro... — committed to andersk/zulip-desktop by andersk 2 years ago

Most upvoted comments

Thinking about this a little more, I think we should actually suppress the new-window event (and the call to the window-open handler) for cmd+click when allowpopups is false. It makes the most sense to have the allowpopups=no mean “this webview is never allowed to spawn a new window”, and also to have new-window mean “we are about to create a new window”.

In the non-nativeWindowOpen situation, “new-window” does not always indicate that a new window will be created, since if allowpopups=no is set, the window creation will be suppressed.

In the nativeWindowOpen situation, the above is true only for cmd+click events—for regular clicks on _blank links and for window.open() calls, there is no event emitted.

Roughly speaking, allowpopups=no should be equivalent to setWindowOpenHandler(() => ({action: 'deny'})).

If your goal is to intercept the creation of new windows, the right way to go is to set allowpopups and install a window-open handler via setWindowOpenHandler. The disposition parameter in the event details can help to distinguish between various kinds of window open events.

The change we should make, then, is to stop emitting new-window / calling the window-open handler when cmd+clicking in a webview with allowpopups=no.

nornagon on Sep 14, 2021

I think we should resolve this by emitting new-window in all cases, i.e. changing the nativeWindowOpen: true behavior to match the nativeWindowOpen: false behavior. We can do this by refactoring the check for ShouldDisablePopups to happen after emitting the event.

nornagon on Sep 13, 2021