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

OK, I've written the spec draft updates. This is complex so I'll re-summarize the above, and we realised there's also a few more cases (d) and (e).

The options that a User Agent might take when the site attempts to navigate to a URL out of scope are:

* a) Continue navigating within the same browser context, with no noticeable UI to indicate you're out of scope
* b) Navigate to the destination within the same app window, but show some UI indicating you're out of scope (e.g., a location bar or banner showing the out-of-scope origin)
  * b1) Navigate the same browser context to the new URL, as with normal HTML, but show UI whenever the page is out-of-scope.
  * 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. 
* c) Create a new browser context in a new window or browser tab, and navigate there.
* d) Open the URL in another browser (i.e., the operating system default browser).
* e) Do nothing (behave as if "not allowed to navigate").

As discussed above, while (b1) and (b2) seem almost the same to the user, they have vastly different characteristics under the hood, and in fact (b2) breaks a lot of sites auth flows, as does (c), (d) and (e).

Current known implementations:

* Chrome for Android: b2
* Firefox on Android: b2
* Chrome OS: c
* Safari on iOS: c

The current behaviour allows for (b2), (c), (d) or (e). The wording is a bit vague and broken; I've uploaded a pull request #700 to reword the existing functionality more precisely.

The new proposed behaviour in #701 switches to allow for (a) (**strongly not recommended**, though we can't mandate it), and (b1). This would require all existing implementations to update so we'll need a commitment to implement from at least a few vendors. However, I think it's a necessary change for this platform, to basically make navigation in an installed app work like navigation on the web. Otherwise, apps that navigate off-scope have subtly different behaviour when running in an installed app.

**Note that this doesn't apply for target=_blank / window.open() navigations**, only self-navigations. This allows user agents to implement either (c) or (d) for target=_blank navigations. (d) is a good option, because if we're pretending these installed apps are like native apps, when they want to open a new browser page, they should open it in the user's preferred browser, not whatever browser the app was installed from. The above proposal does not prevent (d), just (correctly) makes it only possible when the site requests to open the page externally.

-- 
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-402615266