[w3c/manifest] Clarify rule of navigating away from the navigation scope (#646)

Briefly discussed in #550 but spinning out into its own issue / PR.

@marcoscaceres @kenchris I think we want to rework the rule about navigating away from the navigation scope (as part of my work in #550 to remove the concept of "unbounded" scope).

There are currently two major cases: bounded scope (explicit `scope` in manifest) and unbounded scope (no `scope` in manifest). In the bounded case, you aren't allowed to navigate outside of scope at all, except the user agent is allowed to spawn a new top-level browsing context. In the unbounded case, you *are* allowed to navigate outside of the origin, but there is a recommendation that the UA show the location bar when off-origin (or just open a browser tab).

It makes no sense for these cases to be treated differently (especially as we move away from unbounded scope). But I think the right place to be is somewhere in the middle.

- It isn't clear to me what the practical UI implications of "a new top-level browsing context" means.
- A basic reading of the text suggests that if you have bounded scope, off-scope navigations must either fail, or bounce the user out to a new browser tab. Whereas, if you have an unbounded scope, in the event of an off-origin navigation, the UA may either:
  - a) Continue navigating within the app window, or
  - b) Stay within the app window but show some UI indicating that you're off-origin, along with some location bar, or
  - c) Bounce the user out to a new browser tab.

I think, regardless of bounded vs unbounded, (a) should be banned (because it is insecure, as the user will effectively be browsing the web with no knowledge of where they are), and (b) and (c) should be allowed. On Chrome for Android, we do (b) for both bounded and unbounded scope. Are we violating the spec? Or can we justify it in that showing the UI indicating you are off-origin counts as a "new top-level browsing context" (just not a normal browser window). On Chrome for Desktop, we plan to do (c).

I think the *normative* part of the spec (that applies to bounded scope; after #550 this will always apply) should be clear that (b) or (c) are both permitted.

Further problems. In the bounded case, the paragraph under §4 applies:

> The user agent MUST navigate the application context as per [HTML]'s [navigate algorithm](https://html.spec.whatwg.org/#navigate) with exceptions enabled. If the URL of the resource being loaded in the navigation is not within scope of the navigation scope of the application context's manifest, then the user agent MUST behave as if the application context is not allowed to navigate. This provides the ability for the user agent to perform the navigation in a different browsing context, or in a different user agent entirely. If during the handle redirects step of HTML's navigate algorithm the redirect URL is not within scope of the navigation scope of the application context's manifest, abort HTML's navigation algorithm with a `SecurityError`.

This has a few problems:

1. As discussed on #644, there is no "handle redirects" step of HTML's navigate algorithm. Not sure how to fix this.
2. "with exceptions enabled". I'm not sure why this is here. Turning on exceptions makes navigation automatically fail with a `SecurityError` if it's not allowed to navigate (i.e., if it goes out of scope). That nullifies the next sentence: "This provides the ability for the user agent to perform the navigation in a different browsing context". No, it doesn't; if exceptions were disabled, then the navigation algorithm explicitly allows the UA to open in a new top-level browsing context. So I think "with exceptions enabled" should be removed, and similarly, the text for aborting with `SecurityError` should be reworked.

I think we just need some language that says the UA MUST create a new top-level browsing context when navigating off-scope, and somehow explain that this doesn't have to be a normal browser window; it can be within the application window but has to show the location bar (or does that language have to be non-normative?)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/646