Public bug reported: 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. ** 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/1470268 Title: Implement a ResourceThrottle based navigation intercept Status in Oxide Webview: Triaged 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 -- 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
