ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

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