Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add_NewWindowRequested does not handle Shift and middle mouse click #168

Closed
TcT2k opened this issue Apr 28, 2020 · 9 comments
Closed

add_NewWindowRequested does not handle Shift and middle mouse click #168

TcT2k opened this issue Apr 28, 2020 · 9 comments
Labels
bug Something isn't working

Comments

@TcT2k
Copy link

TcT2k commented Apr 28, 2020

While opening new windows via the context menu has been fixed in the latest release (see #108
Using Shift+Left Mouse Click or Middle mouse click still opens a new window without triggering the new window event.

I would expect the NewWindowRequested event to be triggered or at have another mechanism to detect and/or deny such actions.

AB#26187414

@ukandrewc
Copy link

While we're on NewWindowRequested, target doesn't seem to be available anywhere.

@david-risney david-risney added the bug Something isn't working label Apr 28, 2020
@david-risney
Copy link
Contributor

Thanks @TcT2k I would also expect that. We'll look into it.

@ukandrewc, that sounds like a feature request. At the point that we're firing a NewWindowRequested we've already interpreted target and figured out that we need to handle the navigation in a new window. Do you need to do additional work on the target?

@ukandrewc
Copy link

@david-risney, yes. route it to a tab of the same name, if it's already open.
It can be done getting the target from the DOM, when a link is clicked and patching window.open, but it would be great if NewWindowRequested was called before you handled it, with target as an additional property of NewWindowRequestedEventArgs. Thanks

@ukandrewc
Copy link

Just thought, unless you would route to an existing target if there is one?

@david-risney
Copy link
Contributor

Yes we currently respect the target and route to the existing WebView2 if there is already one and otherwise can end up firing the NewWindowRequested event.

For example, if in webview A in script you do window.open(url1, "exampleTargetName") then webview A will fire NewWindowRequested event. If you provide a new WebView2 webview B in that event to be the new window, then webview B will be used to navigate to url1. Then back in webview A you do window.open(url2, "exampleTargetName") webview B will navigate to url2 without NewWindowRequested firing.

Did you want the target so that you could handle it correctly like described above, or are you trying to do some custom handling of the target?

@ukandrewc
Copy link

That workflow is just what we need for our tabbed browser. The only thing that may be useful, is to have the target in NewWindowRequestedEventArgs.

@TcT2k
Copy link
Author

TcT2k commented Oct 21, 2020

@david-risney The middle mouse click issue is still not resolved in the GA version

@pagoe-msft
Copy link

Hi Everyone,

This issue has been resolved in the 1.0.707-prerelease package.

@TcT2k
Copy link
Author

TcT2k commented Nov 24, 2020

Just tested with Edge canary, and can confirm it works. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants