ubuntu-webapps-bugs team mailing list archive

[Chris Coulson <chris.coulson@xxxxxxxxxxxxx>]

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