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