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

So "unbounded" scope is gone, which simplifies things a lot.

The main question I am trying to answer is: *do we need a normative change to allow a navigation out-of-scope within the same browser context, as long as UI is shown to make it clear you are out of scope*. TL;DR: No, we should not (at this time) make a normative change. Thus I will just reword the paragraph to make things clearer.

**Long explanation**

In my initial report, I detailed 3 cases marked (a), (b) and (c). I'm going to split (b) into two sub-cases because it's a bit more nuanced:

A navigation that *would normally* stay within the same context (e.g., a left-click on a non-targeted link) could, when in an app context:

- a) Continue navigating within the same browser context, with no noticeable UI to indicate you're out of scope, or
- b1) Continue navigating within the same browser context, but show some UI indicating that you're out of scope (e.g., a location bar or banner showing the out-of-scope origin), or
- b2) Create a new browser context and navigate there, but have the new browser context exist within the app window, *covering over* the app's browser context, and show some UI indicating that you're out of scope (e.g., a location bar or banner showing the out-of-scope origin), or
- c) Create a new browser context in a new window or browser tab, and navigate there.

Previously (before #647 removed unbounded scope), unbounded scope allowed the UA to perform any of the above, but RECOMMENDED (b1), (b2) or (c) (because (a) presents a security risk, as the user would not realise they are off-origin). The current text requires (b2) or (c), i.e., that a new browser context is created. You cannot navigate an application context out of scope, but you can create a new browsing context within the same application window (b2), or just bounce the user out to a separate browser tab (c), or even a different browser.

In Chrome for Desktop, we do (c). In Chrome for Android, we do (b2). A previous implementation on Chrome for Desktop was doing (b1) but we decided it was clearer to go with (c).

What I have been trying to think about is *is there any material difference between (b1) and (b2)*, and if so, should we also allow (b1)? In other words, can the user or developer (of either the source or destination page) tell the difference between:

- (b1), a simple navigation from in-app to out-of-app, which goes back to the in-app page when you press the back button, and
- (b2), a new browsing context covering over the in-app page, which closes to reveal the in-app page when you press the back button.

The answer is "yes", for a couple of reasons:

1. In (b2), the JavaScript code for the source page continues executing even though the page is hidden. (Even on Android where it is pushed into the background.) We tried using `setInterval` and the source page was able to console.log and even open new windows repeatedly while the page was hidden. In (b1), the source page does not exist while the destination page is open.
2. In (b1), the destination page can see the source page in `window.history`, and can navigate back to it with `window.history.back()`. In (b2), the destination page has no history.
3. In (b2), the destination page can see and communicate with the source page with `window.opener` (e.g., can `postMessage` to it, and learn lots of details if it is on the same origin). In (b1), there is no opener because the source page context no longer exists.

So there are a few noticeable differences, and therefore, I think it's prudent to continue to disallow (b1). If a user agent wants to implement (b1) behaviour for out-of-scope navigations, we can discuss allowing this at a later time.

In the mean time, I will rewrite that paragraph to make it clearer what is allowed and what is not, but not change the semantics.

Thanks to @g-ortuno for helping with the above exploration.

-- 
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#issuecomment-371712028