Re: [w3c/manifest] Clarify the definition of "navigation scope", "applied", and off-scope theming (#880)

> However, now that I better understand the rationale I have another concern. Does this change not break the concept of deep linking as described in [section 3.2](https://www.w3.org/TR/appmanifest/#deep-links) and the Abstract section?
> 
> If all off-scope navigations must stay inside the current application context (but with added chrome), it is no longer possible to deep link between installed web applications. At least not within the constraints of the Android and iOS application frameworks.
> 
> The Firefox OS 2.6 example I gave above actually most closely resembled option b1, but deep linking was possible because it essentially removed the distinction between an app window and browser window. It was therefore possible to seamlessly transition between the two states. A single browsing context could transition between having different manifests applied and the same window could effectively transition from one app to another. As far as I know that is not possible on Android or iOS.

I think I understand that concern. There's some degree of incompatibility between the following two designs:

1. Navigating _from_ an in-scope URL in an app context _to_ an out-of-scope URL remains in the app context, but with a navigation bar UI. [That's the behaviour I'm trying to capture.]
2. Navigating _from_ a normal browsing context _to_ an in-scope URL transitions into an app context. [That's what you're talking about above as deep links.]

The sort-of-incompatibility comes from the inconsistency that when moving _outwards_, the app context is fixed, but when moving _inwards_, the app context changes. To your point, when moving _from_ an in-scope URL in an app context _to_ a URL in another app's scope, there's direct conflict between the above two.

The way this resolves in my mind is that a browsing context never changes its application context. Number 2 above isn't true. If you ever navigate to a URL inside another app's context that is explicitly captured by that app (see #764), then it should not simply transition the current browsing context into an application context, it should create a new top-level browsing context in that new app context. That's how native apps typically work; you don't somehow "transform" one app window or activity into that of another application. You construct a new activity in that new application.

I think the whole model is simpler, and consistent, if we don't allow a top-level browsing context to change which manifest is applied to it (if any) once it has been created.

-- 
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/pull/880#issuecomment-646434113