ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

Public bug reported:

I've never really been all that happy with the way that the current API
works - where navigationRequested is used as part of the path for
opening a new webview as well as current-tab navigations. This was only
really implemented like this because of an issue with not being able to
make a policy decision in newViewRequested (ie, you currently can't
decide to not create a webview in newViewRequested), but the
implementation is making it difficult to improve the API.

What I want is something like this:

WebView.navigationRequested2:
- Emitted for navigation requests in the current view.
- Provides url / userGesture properties.
- Emitted twice per navigation - PreStart and PreCommit, allowing embedders to make a decision on the original request URL and the final pre-commit URL after redirects. We are able to do this with bug 1470268.
- Provides an API for transferring the navigation to another webview (not sure if this is possible yet, but I think it is. It would be a nice to have anyway)

WebView.newViewRequested2:
- Emitted before a request starts.
- Provides url / userGesture / disposition / position properties.
- Allows the request to be attached to an already existing WebView (not sure if this is possible yet, as it means discarding the already created WebContents. Although, this is essentially the same as not creating a WebView so if we solve that problem then it should be fine)

** Affects: oxide
     Importance: Medium
         Status: Triaged

** Changed in: oxide
   Importance: Undecided => Medium

** Changed in: oxide
       Status: New => Triaged

-- 
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/1499333

Title:
  Implement new navigationRequested / newViewRequested APIs

Status in Oxide:
  Triaged

Bug description:
  I've never really been all that happy with the way that the current
  API works - where navigationRequested is used as part of the path for
  opening a new webview as well as current-tab navigations. This was
  only really implemented like this because of an issue with not being
  able to make a policy decision in newViewRequested (ie, you currently
  can't decide to not create a webview in newViewRequested), but the
  implementation is making it difficult to improve the API.

  What I want is something like this:

  WebView.navigationRequested2:
  - Emitted for navigation requests in the current view.
  - Provides url / userGesture properties.
  - Emitted twice per navigation - PreStart and PreCommit, allowing embedders to make a decision on the original request URL and the final pre-commit URL after redirects. We are able to do this with bug 1470268.
  - Provides an API for transferring the navigation to another webview (not sure if this is possible yet, but I think it is. It would be a nice to have anyway)

  WebView.newViewRequested2:
  - Emitted before a request starts.
  - Provides url / userGesture / disposition / position properties.
  - Allows the request to be attached to an already existing WebView (not sure if this is possible yet, as it means discarding the already created WebContents. Although, this is essentially the same as not creating a WebView so if we solve that problem then it should be fine)

To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1499333/+subscriptions