ubuntu-webapps-bugs team mailing list archive
-
ubuntu-webapps-bugs team
-
Mailing list archive
-
Message #03439
[Bug 1470268] Re: Implement a ResourceThrottle based navigation intercept
** Changed in: oxide
Status: In Progress => 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/1470268
Title:
Implement a ResourceThrottle based navigation intercept
Status in Oxide:
Fix Released
Bug description:
WebView.navigationRequested currently relies on us turning on an
option in Chromium to delegate top-level navigations to the browser
process, which allows applications to intercept them. There are some
issues with the current approach though:
- This navigation path is not used in Chromium, and it's not clear how well tested it is.
- I'm not really sure where it fits in with the re-work of navigations in Chromium (https://docs.google.com/document/d/1cSW8fpJIUnibQKU8TMwLE5VxYZPh4u4LNu_wtkok8UE/edit).
- It relies on us implementing some of our own navigation logic in oxide::WebView.
- Navigations that should open in a new tab follow a different code path to window.open() - they go through our navigation logic, and it's impossible to tell whether we should suppress the opener (we never supply the opener to the new webview, which is wrong).
- This navigation mechanism in Chromium doesn't support POST requests, so the application never has a chance to intercept these.
We should use the normal navigation paths in Chromium, and instead use
a ResourceThrottle to intercept navigations. This will introduce a
small behavioural change in the API - currently,
WebView.navigationRequested fires before a load starts. With this
change, a load will start before WebView.navigationRequested fires,
and it will be followed by a Stopped or Committed load event depending
on the decision.
In the future, this will allow us to intercept navigations later -
just before the load is committed when we have the final URL. However,
because requests to open a new webview will always have the initial
URL and they both share the same API (WebView.navigationRequested), I
don't intend to change this just yet. Instead, I plan to provide a
replacement set of API's that decouples navigations and window opening
entirely.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1470268/+subscriptions
References