I ended up fixing this without adding a third signal in the end.
Instead, it now dispatches WebView.navigationRequested for *all*
requests to open a new window, regardless of the origin of these. This
is dispatched before any resources are created and should be used if the
application wants to block a window from opening.
WebView.newViewRequested is now always dispatched when the underlying
WebContents is ready to display. If an application implements this, it
is expected that it creates a new WebView. It shouldn't be used for
policy decisions (use navigationRequested for that), so I've removed
NewViewRequest.url and NewViewRequest.userGesture to discourage this.
I'll probably make it output a console warning if an application
implements this but doesn't create a WebView.
** Changed in: oxide
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1300891
Title:
Refine WebView.navigationRequested and WebView.newViewRequested
Status in Oxide Webview:
Fix Released
Bug description:
I initially thought that all top-level navigations would result in
WebView.navigationRequested firing, and that this could be used to
block all navigations whether they are going to happen in the current
webview or not (accepting a navigation with disposition != CurrentTab
would then result in WebView.newViewRequest firing, and the
application creating a new WebView). Using WebView.newViewRequest to
block a navigation in a new view doesn't really work correctly at the
moment due to bug 1300884.
However, there are some exceptions which make the current API a bit
confusing:
- window.open() only results in WebView.newViewRequested (although I knew
about this one)
- Clicking on an anchor with target="_blank" only results in
WebView.newViewRequested
- Clicking with modifiers on an anchor that has no target results in both
WebView.navigationRequested and WebView.newViewRequested.
- Subframe navigations that have a disposition of CurrentTab don't result in
any signal, but this one is expected.
- Browser-initiated navigations don't result in either signal, but this is
deliberate too.
I think this should probably be cleaned up by:
- Removing NavigationRequest.disposition and only dispatching
WebView.navigationRequest for top-level renderer-intiated navigations for the
current view.
- Dispatch only WebView.newViewRequested for all navigations that are not
destined for the current WebView, which requires fixing bug 1300884 so that
this can be used to reject requests.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1300891/+subscriptions
--
Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
More help : https://help.launchpad.net/ListHelp
