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